増田さんに聞く！ ドメイン駆動設計の実践技法
ドメイン駆動設計ではなくソフトウェア設計としても参考になる。
事業活動の分析を中心に書かれている
要約 「事業活動とソフトウェアを一緒に発展させていくための方法」
事業活動とソフトウェアを一緒に発展させていく
「基本となる考え方」「実装方法の選択」 「現場での取り組み方」「分散型システムへの挑戦」
第1章１〜４＝＞を義日者が理解してから後半
| 原語 | 従来の訳語 | 本書の訳語 |
|---|---|---|
| domain | ドメイン | 事業活動 |
| subdomain | サブドメイン | 業務領域 |
| domain logic | ドメインロジック | 業務ロジック |
| core domain | コアドメイン | 中核の業務領域 |
| ubiquitous language | ユビキタス言語 | 同じ言葉 |
| bounded context | 境界づけられたコンテキスト | 区切られた文脈 |
| context map | コンテキストマップ | 文脈の地図 |
技術者がドメインとサブドメインを理解し 境界づけられたコンテキストでユビキタス言語を使って ソフトウェアを開発する ⇩ 技術者が事業活動と業務領域を理解し 区切られた文脈で同じ言葉を使って ソフトウェアを開発する
現実世界のドメイン駆動設計
こういうことはありえないし、必要もない（第13章） チーム全員がドメイン駆動設計を熟知している 最初から全員が役に立つモデルの探求に全力をつくす 全ての関係者が同じ言葉を忠実に使う 既存システムや外部サービスを考慮しなくてよい制約の少ない新規案件 ＞ドメイン駆動設計のすべての技法を使う必要はない ＞ドメイン駆動設計が組織として受け入れられていない状況でも実践は可能 ♥適切な道具を必要に応じて選択的に使う くそれぞれのやり方の背景にある考え方と原則を意識して使う ♥組織の変化とソフトウェアの成長に忍耐強く取り組む
「付録」の失敗談。
Railsマッチしている？
エンティティの重要度は下げて書かれてる エヴァンスにはどちらかというと批判的
エヴァンス本も見るべき
初学者もこの本 いいと思う。
エンティティを跨ぐバリデーション
＞エンティティの重要度は下げて書かれてるのはあまり重要じゃないからかな？
複雑なメインロジックが問題意識
金銭、日付、数量扱ってるか？ ValueObject →集約で表現する エンティティありきの設計にはならないよ。
ValueObject、エンティティ 違う捉え方。
この本の方がわかりやすい。
エンティティ關係ないと言い切ってるのは違和感ある。
DTOに関して 業務知識が表現できてれば
ストリーミングURL: https://streamyard.com/watch/v3RiZxRA3bED
