domain-driven-design

ドメイン駆動設計

Learning Domain-Driven Design（Vlad Khononov、O'Reilly）の観点から、変更におけるドメインの形状をレビューします。DDDには、組み合わせて使う2つの視点があります。

• 戦略的（第I部、第III〜IV部） — 境界がどこにあるか：境界づけられたコンテキスト、ユビキタス言語、コンテキストの統合方法。
• 戦術的（第II〜III部） — 1つのコンテキストをどう構築するか：ビジネスロジックのパターン、そして集約／値オブジェクトが不変条件を保持し、安全にイベントを公開するかどうか。

これは、一般的なレイヤー構成／凝集度のチェックでも、トレードオフ／連接性の監査（architecture-lens を使用）でも、マクロなスタイル選定やサービス分割（macro-architecture を使用）でも、バグ探し（code-review を使用）でもありません。

レビューの選択

変更	参照先
境界づけられたコンテキストを移動または横断する、ビジネス上の命名を変更する、あるいは別のシステムと統合する	references/strategic-review.md
1つのコンテキスト内で、ビジネスロジック、集約、値オブジェクト、ドメインイベントを構成する	references/tactical-review.md
両方に該当する	まず戦略的レビューを行い、次に該当する戦術的ルールを適用します。境界が内部設計を制約します

該当する観点だけを適用します。指摘事項には、ファイルと行、ルール、修正案を記載します。問題のない観点について、無理に指摘を作り出す必要はありません。

コンテキストマップの導出： 物理的な境界づけられたコンテキストは通常、バックエンドのサービス／モジュールに対応し、それぞれがモデルとユビキタス言語の一部を所有します（例：トランザクション中核サービス、統合／同期サービス、イベントワーカー、ドメインエンティティの共有カーネル、フロントエンド独自のAPI層モデル）。レビューの前に、リポジトリのサービス／モジュール構成からこのマップを導出します。_サブドメイン_は問題領域（価格設定、配送、コンプライアンス）であり、_境界づけられたコンテキスト_は1つのモデル／言語が成立するソリューション境界です。両者は一致することが多いものの、常に一致するとは限りません。

根拠と出力

選択した手法には、単独で使用する場合の出力形式が記載されています。影響の最も大きい指摘から始め、根拠と未解決のドメイン上の判断を区別します。

design-gate のもとでは、読み取り専用のまま、呼び出し元が定めた標準のゲート結果を使用します。実際の不変条件と統合境界を維持してください。見た目に関する好みは助言にとどめます。

詳細なリファレンス

• references/context-patterns.md：コンテキスト間の関係を分類する前、または指摘に完全な定義が必要な場合に読み込みます。
• references/decision-trees.md：パターンの分類が微妙な場合や、集約、値オブジェクト、イベントの詳細なチェックを行う場合に読み込みます。

インタビューでは、判断、根拠、制約、参照元を既存の意思決定記録に追加します。この段階では、単独のレポートや実装の進め方は適用されません。