Upgrade to Pro — share decks privately, control downloads, hide ads and more …

レガシーなプロダクトからドメイン層を再設計する / iOSDC_takahashi_ishii

Recruit
September 09, 2022

レガシーなプロダクトからドメイン層を再設計する / iOSDC_takahashi_ishii

2022/09/11_iOSDC Japan 2022での、高橋/石井の講演資料になります

Recruit

September 09, 2022
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. 自己紹介 石井 潤 • 株式会社リクルート( 2018.04-) • iOS/Android App Developer

    (2018.10-) 高橋陽太郎 • 株式会社リクルート • Engineering Manager
  2. これまでのあらすじ:混乱に秩序をもたらすリアーキテクチャ奮闘中 での出来事 View 肥大化。 ロジックやデータが モリモリに入ってい る Presenter ほぼログ送信のロ ジックしかなく薄すぎ

    る Model APIやDBアクセス レイヤリングを適切にする ことでFat Viewから脱却 したい。 なぜか依存している DBアクセス用のモデル を生成してたりする
  3. そしてFat Presenterが出来上がった View 表示とイベント通知 (簡素化に成功) Presenter 画面表示のための データやフラグ、 ビジネスロジック。 大量の状態を持っ

    て肥大化。 UseCase ほぼRepositoryの ラッパー Repository ほぼDataAccessの ラッパー DataAccess APIやDBアクセ ス DomainModel
  4. これがやりたかったことではなかったはずなのに、どうしてこうなったんだろう? View 表示とイベント通知 (簡素化に成功) Presenter 画面表示のための データやフラグ、 ビジネスロジック。 大量の状態を持っ て肥大化。

    UseCase ほぼRepositoryの ラッパー Repository ほぼDataAccessの ラッパー DataAccess APIやDBアクセ ス DomainModel 【疑問】 状態を置くレイヤーが適切ではない のでは? Presenter 画面表示のための データやフラグ、 ビジネスロジック。 大量の状態を持っ て肥大化。
  5. ここまでの気づき • 我々エンジニアはすぐに実装やレイヤリングに目がいってしまうが、それではドメイ ンモデルには辿り着かない。 • 実装から離れて、0ベースでドメインのことを考える。 ◦ まずはアプリの本質、どんな価値をユーザーに提供するかを考える ◦ その際、UI/DB/APIなど実装上の制約は考えない

    ◦ 別のUIや実行基盤でも考えてみて同じように価値を提供できるか確認する • これらを意識してモデリングをしてみたら、レイヤリングに注力していた最初期から はアプリの捉え方、認識の仕方がまるっきり変わっていた。 ↑スライドの途中ですが一番伝えたかったことです。
  6. TIP2: ドメインモデルは現実よりも複雑で豊かなり タウンワークにおける検索時の駅選択のモデリング 【仕様①】 基本的にはユーザーが 選択している都道府県 の駅が選択できる 【仕様②】 同一路線上の他の都道 府県の駅が選択できる

    【仕様③】JR中央本線 の「新宿駅」を選択する と、別路線の新宿駅も 選択状態になる。 【仕様④】 ユーザーには選択した 都道府県+選択した駅 名で表示する
  7. TIP3: アプリの中のドメインモデリング • サーバーでモデリングを頑張りそれを表示するだけなら、アプリのモデリングは必要な い? ◦ 確かにそういうデータも存在する ◦ 例えば求人詳細の給与や時間を立体的なモデルにしてもうまみがない (左図)

    • でも、我々アプリの本質は「ユーザーと求人とのインタラクション」を実現すること。それ にまつわるドメインモデリングはアプリでも必要だった。 ◦ 例えば閲覧履歴や検索条件など、ユーザーと求人の関係を促進するためのデータはモデルにする価 値がある(右図)
  8. TIP5:モデルもメンテナンスする? モデルとコードの関係 • モデルとコードは一体 • 行ったり来たりしてフィードバックし合う ◦ モデルだけだと抽象的すぎて要素を見落とすことがあるし、コードだけだと具体的すぎて全体が見えなく なる ◦

    どちらかで変更があればもう一方にも反映する ▪ 項目→応募入力項目に名前変更 • コードが書けたならモデル(図)はメンテナンスしなくて良い? ◦ それぞれ目的が違う ▪ モデルは全体を俯瞰するために有用 • 全体像、要素の関係を把握しやすい • 仕様変更(新たな仕様)の際に全体の中での位置、既存の要素との関係がすぐわかる モデル コード 全体、俯瞰、 要素の関係 具体、詳細
  9. まとめ このセッションで触れた内容 • アーキテクチャに秩序をもたらすべく、リアーキテクチャに取り組んだらFat Presenterになってしまった • レイヤリングに意識を向けていたが、ドメインを掘り起こす作業の中で、アプリケー ションの本質を理解することが重要だと気づいた • モデリングする上でたくさん疑問にぶつかり、それらに自分たちなりの解答を出せ

    た ◦ ドメインには事実を持たせる?情報を持たせる? ◦ ドメインは現実世界のものと対応するべき? ◦ サーバーサイドではなく、アプリでもドメインに注意を払う必要ってあるの? ◦ 作ってみたドメインがしっくりきているかってどうやったらわかるの? ▪ 気づいたらテストコードの書き方も練度が上がっていた ◦ 動作するコードが出来上がったら、モデルもメンテナンスしなければいけないの?
  10. 一番衝撃的だったのは、ドメインに意識を向ける中で我々のアプリ の捉え方がガラッと変わったこと このセッションで触れた内容 • リアーキテクチャに取り組んだらFat Presenterになってしまった • レイヤリングに意識を向けていたが、ドメインを掘り起こす作業の中で、アプリケー ションの本質を理解することが重要だと気づいた •

    モデリングする上でたくさん疑問にぶつかり、それらに自分たちなりの解答を出せ た ◦ ドメインには事実を持たせる?情報を持たせる? ◦ ドメインは現実世界のものと対応するべき? ◦ サーバーサイドではなく、アプリでもドメインに注意を払う必要ってあるの? ◦ 作ってみたドメインがしっくりきているかってどうやったらわかるの? ▪ 気づいたらテストコードの書き方も練度が上がっていた ◦ 動作するコードが出来上がったら、モデルもメンテナンスしなければいけないの?