SwiftでDDD(ドメイン駆動設計)

Swiftあるある(行き当たりばったりで開発した時)

• ViewControllerが色んな機能を持っていて肥大化して、読みにくい
• helperの場所が人によってまちまち。どこで使ってるのか解りにくい。
• 一つ機能を追加しようとすると、影響範囲が広すぎる。

※ swiftでもobjective-cでも同じですが、swiftから触り始めたのと
今あえてobjective-cに触れる必要がなさそうなので、swiftの表記にしています。

ドメイン駆動開発（DDD）とは

業務的関心事のドメインモデルを中心に
UIやコードをドメインモデルに一体化させる考え方。

キーワード

• ドメイン駆動開発（DDD)
• ユースケース駆動開発（UCDD)
• クリーンアーキテクチャ
• MVP

資料

• 1.[The Clean Architecture]
  (http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html)
• 2.[MVCモデルの問題点を解決するPMモデルとMVPモデル]
  (http://geekna.hatenablog.jp/entry/20110823/p1)

ドメイン駆動開発の層分け

クリーンアーキテクチャ

資料1より

• 世界観としてはEntitiesを中心に、DBやUIが外界とする。
• 外界からは中の様子は知れるが、中から外は無関心である。

Swiftでやってみた

MVP

MVPの考えも入れています。
資料2より

swiftでは

• Viewはプロトコルで実装
• ViewControllerがViewのプロトコルを継承し、Presenterに通知する。
• PresenterはViewControllerから通知を受け取り、Viewに表示命令、usecaseに実行命令を渡す。

今回はinitとviewDidLoadの役割は以下のように分けました。

ViewController

• viewDidLoad()
  • Presenterのアタッチ、呼び出し
  • TableViewのCustomCell設定
  • refleshControllの設定
  • dateFormatterの設定

Presenter

• init()
  • viewのアタッチ
  • インスタンス設定
• viewDidLoad()
  • viewの表示設定

手順

• 1. ユースケースを出す。
• 1. ユースケース層からドメイン層を設計する。
• 1. データ層を設計する。
• 1. UI層を設計する。

レビューもこの順番が見やすい様です。

UI層

• View:
  Protocolで実装
• ViewContoroller:
  ViewのProtocolを継承
• Presenter:
  ViewControllerから事実を受け取ってUsecaseに通知する。

Domain層

• Usecase:
  通信する時はここで非同期に
  ここでアプリが何をしているか判断できる。
• Repository:
  Protocolで実装
• Entity:
  取引するデータの型

データ層

• Reposotory:
  Protocolで実装
  データ層のCRUDをもつ(Railsで言うActiveRecord)
  moc作りやすい
• Api:
  RepositoryのProtocolを継承
• CoreData:
  CoreData操作
• Entity:
  データ層個別で取引するデータ型
  （なくても良い）

今回の利点

• Presenter,Usecaseでアプリの概要がわかる

• 各クラスの責務を分けたので、それぞれで完結していて変更しやすい。

  • データ取得元を追加したい時、ちょっと追加するだけなので拡張しやすい
  • 機能追加も他と独立して追加できる。

• テストしやすい

  • Data層のrepository層でmocを作ってテストデータで開発ができる

苦労した点

• デタッチアタッチの概念
  swiftが勝手にやってくれていると考えていたweak接続とデタッチタイミングをちゃんと調べなおしました。(汗