DDD
ざっと全体を俯瞰したい人向けの資料
事業上重要なドメイン
支援サブドメイン
コアドメインを助けるドメイン
こっちも事業上重要
ビジネス上重要でないが必要なドメイン
におい
解決したい問題が異なるなら、別のサブドメインになる
におい
別チームなら別のコンテキストを持っているはず
問題意識
コンテキストどうしのやり取りをしたい
コンテキストとコンテキストの関係性をあらわす
分類されてる
consumer/supplier がとれない場合につかう
どんなとき
supplierにメリットがないとき
何をする
supplierのドメイン用語をcustomerが使う
より深く
実践
フロントでの活用事例]
kadoyau.icon
実装(エラー処理やキャッシュ戦略やミドルウェアの都合)にとらわれず、そのアプリケーションのやりたいこと（コアドメイン）をコードで表現するためのメソドロジー
用語の統一（ユビキタス言語）やコードの整備から要求〜開発の全体最適を図る
気軽に取り組むのがよさそう
本読んでも何言ってるのかわかんない、というようなことが結構あるが、わかるところからはじめるのがいい
チームで共通の理解が必要なので、一人でできることではない
複数人のチームで1人だけDDDします、とかは無理
https://gyazo.com/eee1fd724762daef296db31db43dcfff
業務で困らないとありがたみが理解しにくいので具体例（自分たちのコードベースでの例）が理解に重要
本に書いてある抽象的な議論を真似ようとすると、ディレクトリ構成だけマネたなんちゃってDDDになる
例：domainとinfraが切り分けられているのにdomainの中にinfraに依存したコードが交じる
2018年の自分の理解（1つのアプリケーションの場合。複数のアプリケーションにまたがる場合は別スコープ）
理由1. インフラの都合に縛られないのでドメインコードはビジネスロジックの凝集度が高いから このため、枝葉にとらわれずに何をしたいのかが（理想的には）わかる
理由2. インフラとドメインがレイヤリングされているので、インフラの変更がドメインを歪めない
コードの変更の目的が切り分けやすい
コードの変更も少なくて済む