Swiftあるある(行き当たりばったりで開発した時)
- ViewControllerが色んな機能を持っていて肥大化して、読みにくい
- helperの場所が人によってまちまち。どこで使ってるのか解りにくい。
- 一つ機能を追加しようとすると、影響範囲が広すぎる。
※ swiftでもobjective-cでも同じですが、swiftから触り始めたのと
今あえてobjective-cに触れる必要がなさそうなので、swiftの表記にしています。
ドメイン駆動開発（DDD）とは
業務的関心事のドメインモデルを中心に
UIやコードをドメインモデルに一体化させる考え方。
キーワード
- ドメイン駆動開発（DDD)
- ユースケース駆動開発（UCDD)
- クリーンアーキテクチャ
- MVP
資料
ドメイン駆動開発の層分け
クリーンアーキテクチャ
資料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. ユースケースを出す。
- 2. ユースケース層からドメイン層を設計する。
- 3. データ層を設計する。
- 4. 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接続とデタッチタイミングをちゃんと調べなおしました。(汗