ドメイン駆動設計
「コアドメイン」と「サブドメイン」
サブドメイン
差し替え可能
例として認証・アクセス管理用
コアドメインほど重要でないドメイン
アジャイルプロジェクト管理用
サブドメイン
汎用サブドメイン
支援サブドメイン
エンティティが属性として値オブジェクトを持ったりする。
値オブジェクトを入れ替えてエンティティの属性を変更する
エンティティが人間
１０円玉が値オブジェクトとか
エンティティ
もし、エンティティの生成が複雑な場合はコンストラクタを直接呼び出すのではなく、ファクトリ（11章）を使用します。
値オブジェクト
副作用がない
不変
交換可能
値の等価性
型が等しく、属性が等しければ同じものとみなす
ドメインサービス
状態を持ってはいけない
ユーザーとロールの切り離し
列車事故とかではなく、問題なのはモデルの混乱
コンテキストマップ
解決空間の全貌を俯瞰する
コンテキスト間
パートナーシップ
共有カーネル
コード共有
腐敗防止層
変換層
別々の道
巨大な泥団子
コンテキスト内では、きれいにモデリングしようとしないこと
システム変更の影響が他のコンテキストに及ばないようにすること
腐敗防止層
コラボレーションコンテキストが認証コンテキストに対して権限を持つユーザーのリソースを問い合わせることなど
リクエストしたリソースをXMLやJSONなどで受け取ったりするかもしれない
アーキテクチャ
使わなければ、リスクが増大する可能性があるときに使う
イベント駆動アーキテクチャ
重複を削除するため
実行者が状態追跡用オブジェクトをチェックして、同じイベントの完了記録が登録済みでないか確認する
または状態追跡用オブジェクトが冪等になるように設計
CQRS
クエリプロセッサ
コマンドプロセッサ
クエリモデル
バリデーション
エンティティ自身に何をバリデーションするか決めさせて、クライアントからは考えないようにする
細かいバリデーションをする手も有る。エンティティ知らない。
複雑なエンティティの作成はファクトリを使う
同一モジュールに有るクラスしかそのエンティティのインスタンスを作成できない
依存性注入は避けるべきなのか
ガベージコレクションを考えて
アプリケーション
コアモデルとやり取りしたり、
参考
コンテキストの統合
参考書籍
実践ドメイン駆動設計
-------------
マイクロサービス
SOA
サービス指向アーキテクチャー
マイクロサービス境界
コンテキストマップ作成ツール
ドメイン駆動事例
レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡
ドメインエキスパートの知見
ソフトウェアの拡張性を正しい方向で意識できる
手を抜くべき場所や重要な箇所が明確になる
ドメインエキスパートの案より良い解決手段を提示できる。
ユビキタス言語の策定
コミュニケーションずれ解消
説明コスト削減