# ドメイン駆動設計 入門 輪読会 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
----
- 大規模なシステムほど統一モデルは非現実的
- 無理に統一するとしがらみの多いオブジェクトに
- コンテキストごとの事情で肥大化→変更しづらい
- 解決策:モデルの捉え方が異なる箇所でシステム分割
- 境界を引いて、コンテキストを分ける
----
### コンテキストマップ
- 境界付けられたコンテキスト
- 👍 細分化されたコンテキストは理解しやすい
- 👎 ドメインの全体像がぼやける
- 特定のコンテキストに集中し、他との関係が見落とされる
- 例:ユーザ識別子の変更と他パッケージ
- 🎉 全体を俯瞰するコンテキストマップ
- モデル同士の関係性を把握して開発を進められる
----
- 境界付けられたコンテキスト=チームの輪郭
- 変更時に影響ある場合、該当チームと要交渉
- 両チームをテストでつなぐ
---
### 今日のまとめ
- 本書のパターンの助けを借りて
ドメインの本質に向き合おう
- ドメインエキスパートと会話して
解決すべき問題を見つけよう
- 『エリック・エヴァンスの
ドメイン駆動設計』へ
{"metaMigratedAt":"2023-06-16T22:13:56.937Z","metaMigratedFrom":"YAML","title":"ドメイン駆動設計 入門 輪読会 vol.15","breaks":"true","slideOptions":"{\"transition\":\"slide\"}","contributors":"[{\"id\":\"df36d0f0-b67e-41ac-96b3-f3988326d230\",\"add\":3824,\"del\":566}]"}