# ドメイン駆動設計 入門 輪読会 vol.15 2022/03/31 [@kdnakt](https://twitter.com/kdnakt) --- ### 今日の範囲 - 15章 ドメイン駆動設計のとびらを開こう ``` 15.1 軽量DDDに陥らないために 15.2 ドメインエキスパートとモデリングをする 15.3 ユビキタス言語 15.4 境界付けられたコンテキスト 15.5 コンテキストマップ 15.6 ボトムアップドメイン駆動設計 15.7 まとめ ``` --- ### 今日の概要 - 本書のパターンの助けを借りて ドメインの本質に向き合おう - ドメインエキスパートと会話して 解決すべき問題を見つけよう - 『エリック・エヴァンスの ドメイン駆動設計』へ --- ### 本書のパターンの助けを借りて ### ドメインの本質に向き合おう ---- #### 本書で学んだパターン - 2　システム固有の値を表現する 「値オブジェクト」 - 3　ライフサイクルのあるオブジェクト 「エンティティ」 - 4　不自然さを解決する 「ドメインサービス」 - 5　データにまつわる処理を分離する 「リポジトリ」 - 6　ユースケースを実現する 「アプリケーションサービス」 - etc ---- #### DDDはどうあるべきか - 🙅‍♂️ パターンを取り入れるだけ = 軽量DDD - 🙅‍♂️ ドメインエキスパートの判断で作るだけ - 🙆‍♀️ パターンの助けを借りて問題を紐解き、 ドメインを主役に据え本質に向き合う --- ### ドメインエキスパートと会話して ### 解決すべき問題を見つけよう ---- ### ドメインエキスパートとモデリング - 認識のズレはよくあること - 複雑で繊細なドメイン概念＋システム用語 - ドメインエキスパートが理解を放棄する - ドメインとコードが断絶：見当違いな方向へ... - ドメインエキスパートと会話すべき - ドメイン概念を捻じ曲げない共通言語で - 技術的なアプローチに傾倒するのは間違い - ドメイン(問題)を知らずに答えは出せない ---- #### 本当に解決すべきものを見つけよう - ドメインエキスパート自身も気づいていない - 本当に解決すべき問題は? - ドメインにおいて有益な概念(ドメインモデル)は？ - どの知識がシステムに役立つのか？ - ドメインエキスパートが関わらないプロジェクトも - 価値あるドメインモデルが作られない - 利用者は不満を持つ ---- - プロダクトオーナーは開発者とドメインエキスパートの会話を増やすよう働きかけるべき - 🙅‍♂️ アプリケーションが何をすべきか考える - 🙆‍♀️ 解決すべき問題が何かを考える ---- #### ドメインとコードを結びつけるモデル - 会話だけでなく、設計や実装時にドメインの気づきを得る - ドメインとコードがモデルでつながる - ソフトウェアに役立つ、知識が凝縮されたドメインモデル --- ### 『エリック・エヴァンスの ### ドメイン駆動設計』へ ---- #### ユビキタス言語 #### 境界付けられたコンテキスト #### コンテキストマップ ---- ### ユビキタス言語 - ひとつの概念に複数の名前がついて混乱する - ソフトウェア開発では容易に発生 - 例：ユーザの登録(ドメインエキスパート)/新規保存(開発者) - 異なる言葉での会話は意思疎通の障害 - ドメインエキスパートから価値あるドメインモデルを引き出すために同じ言葉を ---- - ユビキタス言語：プロジェクトの認識齟齬や翻訳コスト削減のための共通言語 - ドメインエキスパートとの会話 - 開発者同士の会話 - ソースコード上 - 🙅‍♂️ ドメインエキスパートの言語そのまま - 🙆‍♀️ 双方向に改良しお互いを理解し合う ---- #### 深い洞察を得るために - 母語でない＝翻訳が必要＝意味理解にコストがかかる - 同じ言語で会話すればかからないコスト - ユビキタス言語が使われないプロジェクト＝常に翻訳コストがかかっている ---- - ドキュメントに現れないニュアンスを見逃さないために、会話の内容に集中すべき - 理解不足だとドメイン概念からかけ離れたオブジェクトに - 翻訳コストではなくユビキタス言語の策定・維持にコストを払うべき - ドメイン概念を伝える際の扱いにくい用語、曖昧な用語に気づき、深い洞察、ドメイン知識につながる ---- #### ユビキタス言語がコードの表現として使われる - 例：ユーザー名を変更する - 🙆‍♀️ public void changeName(UserName name) // ドメインにとって自然な表現 - 🙅‍♂️ public void updateName(UserName name) // データ更新という実装に着目した表現：翻訳が必要 - ドメインモデルを表現したコード（ドメインオブジェクト） - ドメインの変化を適用しやすい ---- - 自然言語の壁 - ソースを日本語で書くとベスト：制約が大きい - ドメインエキスパート：必ずしも英語堪能ではない - 適切な英訳の問題は残る ---- ### 境界付けられたコンテキスト - ドメインの国境：ユビキタス言語が変わる境目 - 同じものを差しながら言葉が少し違う - 同じ言葉でも意味が少し異なる ---- - SNSアプリケーションの例 - ユーザはサークルを作り所属する - ユーザのログインパスワードを比較する - 無理に同じオブジェクトに同居する必要なし - core.model.Userとauth.model.User ---- - 大規模なシステムほど統一モデルは非現実的 - 無理に統一するとしがらみの多いオブジェクトに - コンテキストごとの事情で肥大化→変更しづらい - 解決策：モデルの捉え方が異なる箇所でシステム分割 - 境界を引いて、コンテキストを分ける ---- ### コンテキストマップ - 境界付けられたコンテキスト - 👍 細分化されたコンテキストは理解しやすい - 👎 ドメインの全体像がぼやける - 特定のコンテキストに集中し、他との関係が見落とされる - 例：ユーザ識別子の変更と他パッケージ - 🎉 全体を俯瞰するコンテキストマップ - モデル同士の関係性を把握して開発を進められる ---- - 境界付けられたコンテキスト＝チームの輪郭 - 変更時に影響ある場合、該当チームと要交渉 - 両チームをテストでつなぐ --- ### 今日のまとめ - 本書のパターンの助けを借りて ドメインの本質に向き合おう - ドメインエキスパートと会話して 解決すべき問題を見つけよう - 『エリック・エヴァンスの ドメイン駆動設計』へ