レガシーなプロダクトからドメイン層を再設計する / iOSDC_takahashi_ishii
Transcript
- (2018.10-) 高橋陽太郎 • 株式会社リクルート • Engineering Manager
- る Model APIやDBアクセス レイヤリングを適切にする ことでFat Viewから脱却 したい。 なぜか依存している DBアクセス用のモデル を生成してたりする
- て肥大化。 UseCase ほぼRepositoryの ラッパー Repository ほぼDataAccessの ラッパー DataAccess APIやDBアクセ ス DomainModel
- UseCase ほぼRepositoryの ラッパー Repository ほぼDataAccessの ラッパー DataAccess APIやDBアクセ ス DomainModel 【疑問】 状態を置くレイヤーが適切ではない のでは？ Presenter 画面表示のための データやフラグ、 ビジネスロジック。 大量の状態を持っ て肥大化。
- ◦ 別のUIや実行基盤でも考えてみて同じように価値を提供できるか確認する • これらを意識してモデリングをしてみたら、レイヤリングに注力していた最初期から はアプリの捉え方、認識の仕方がまるっきり変わっていた。 ↑スライドの途中ですが一番伝えたかったことです。
- 【仕様③】JR中央本線 の「新宿駅」を選択する と、別路線の新宿駅も 選択状態になる。 【仕様④】 ユーザーには選択した 都道府県＋選択した駅 名で表示する
- • でも、我々アプリの本質は「ユーザーと求人とのインタラクション」を実現すること。それ にまつわるドメインモデリングはアプリでも必要だった。 ◦ 例えば閲覧履歴や検索条件など、ユーザーと求人の関係を促進するためのデータはモデルにする価 値がある（右図）
- ◦ インターフェースに変更があると、具象クラス全てに影響が出てしまうため
- 内部状態に強く依存していないか、同じインプットに対して同じアウトプットを返すか ◦ インスタンスを生成する時に長大なセットアップを必要としていないか≒サイズは適切か
- 実際作ってみたことでユースケースに足りない機能があることを発見できた
- -> 仕様書的にテストを書ける b. 状況 -> データの準備、使い回しがやりやすい
- ある程度必要 コード量 動かすためのコードが結構必要 👍必要最小限 パターン網羅 データ準備や操作が大変 👍データ準備は必要、あとは実行するだけ 繰り返し検証 大変 👍簡単
- どちらかで変更があればもう一方にも反映する ▪ 項目→応募入力項目に名前変更 • コードが書けたならモデル（図）はメンテナンスしなくて良い？ ◦ それぞれ目的が違う ▪ モデルは全体を俯瞰するために有用 • 全体像、要素の関係を把握しやすい • 仕様変更(新たな仕様)の際に全体の中での位置、既存の要素との関係がすぐわかる モデル コード 全体、俯瞰、 要素の関係 具体、詳細
- た ◦ ドメインには事実を持たせる？情報を持たせる？ ◦ ドメインは現実世界のものと対応するべき？ ◦ サーバーサイドではなく、アプリでもドメインに注意を払う必要ってあるの？ ◦ 作ってみたドメインがしっくりきているかってどうやったらわかるの？ ▪ 気づいたらテストコードの書き方も練度が上がっていた ◦ 動作するコードが出来上がったら、モデルもメンテナンスしなければいけないの？
- モデリングする上でたくさん疑問にぶつかり、それらに自分たちなりの解答を出せ た ◦ ドメインには事実を持たせる？情報を持たせる？ ◦ ドメインは現実世界のものと対応するべき？ ◦ サーバーサイドではなく、アプリでもドメインに注意を払う必要ってあるの？ ◦ 作ってみたドメインがしっくりきているかってどうやったらわかるの？ ▪ 気づいたらテストコードの書き方も練度が上がっていた ◦ 動作するコードが出来上がったら、モデルもメンテナンスしなければいけないの？