specsfy-specialist-domain-modeling

ドメインモデリング

使用するタイミング

• ドメイン用語が曖昧な場合、2つのコンテキストで同じ言葉が異なる意味で使われている場合、またはルール／不変条件の owner が明確でない場合に使用します。
• 新しいエンティティを設計する前に、それがエンティティ、値オブジェクト、イベント、あるいは単なるプロジェクションなのか明確でない場合にも使用します。
• サービス、データベース、インフラストラクチャのトポロジーを決めるためには使用しません。その場合は $specsfy-specialist-software-architecture を使います。ドメインモデリングはその判断に情報を提供しますが、代わりにはなりません。
• 新しい bounded context によって新しいサービス境界またはデータ境界が生じる場合は、$specsfy-specialist-software-architecture と組み合わせます。

フロー

1. アクター、その目標、発行するコマンド、すでに起きた事実（イベント）、遷移を制約するルールを特定します。
2. ドメインの人々が実際に使っている用語を集めます。既存のテーブル名やクラス名ではなく、類義語や意味の衝突を明らかにします。
3. 具体的なシナリオを作成します。正常系、境界条件、失敗、時間の影響（コマンドが遅れて届いた場合、重複した場合、順序が前後した場合に何が変わるか）を含めます。
4. 各不変条件を常に真である主張として定式化し、owner（書き込み時点でそれを保証できるコンポーネント／集約）を割り当てます。
5. 同時に変更される必要があり、即座に一貫していなければならない振る舞いをまとめます。これによって集約の境界を定めます。クエリの利便性では決まりません。
6. 提案した各境界を、それを横断するケースで検証します。途中に正しいデータがあっても境界が崩れるなら、その境界の位置は適切ではありません。
7. プロジェクトで正式な情報源とされている場所に、用語集、コンテキストマップ、ADR を更新します。並行するモデル文書は決して作成しません。

パターン

• ドメインの語彙（ユビキタス言語）に基づいて命名します。技術レイヤーに基づく名前は避けます（「Manager」「Handler」「Processor」だけではドメインを表しません）。
• エンティティ（識別子＋ライフサイクル）、値オブジェクト（値で定義され、不変）、イベント（すでに起きた事実を過去形で表す）、プロジェクション（派生した読み取り用データであり、信頼できる唯一の情報源ではない）を、それぞれが必要とする振る舞いに基づいて区別します。実装の都合で区別してはいけません。
• 各不変条件は、それを原子的に保証できるコンポーネントと一緒に維持します。調整なしに2つの集約に依存する不変条件は、並行処理のもとで破られます。
• クエリを簡単にするために集約を大きくしてはいけません。複合クエリにはプロジェクション／読み取りモデルを使い、一貫性のために必要な範囲を超えて集約を大きくしてはいけません。
• 同じ用語に正当ながら互換性のないモデルがある場合は、bounded context を分離します（例：「販売」コンテキストの「顧客」と「サポート」コンテキストの「顧客」では、属性やライフサイクルが異なる場合があります）。
• イベントは過去形（「PedidoConfirmado」）、コマンドは命令形（「ConfirmarPedido」）で命名します。動詞の時制の違いによって、すでに起きたことなのか、要求されていることなのかが伝わります。
• 各定義を、それを満たす例と、それに反する反例で検証します。反例のない定義は、実装するには曖昧すぎることがほとんどです。

アンチパターン

• 貧血ドメインモデル：エンティティがフィールドの入れ物（getter／setter）にすぎず、ルールがすべて外部サービスに置かれている状態です。変更時点で不変条件を保証できず、ルールが複数の呼び出し元に分散して、適用し忘れられる可能性があります。
• 同じ名前のフィールド／クラスが2つの bounded context で同じ意味だと決めつけて使うこと。片方のモデルをもう片方の語彙に合わせて歪めることになります。
• 後でデータを結合せずに済むように、「オブジェクトグラフ全体」を覆う集約を作ること。ドメインが求めていない書き込みの競合と並行処理の制約を生みます。
• 正式な情報源（仕様、コード）とは別のファイルにモデルを記録すること。同期されない変更が一度でもあれば、その文書は実際のシステムと食い違います。

検証

• 仕様、コード、UI、列名／テーブル名で使う用語は、同じ概念に対しては統一され、異なる概念に対しては文脈ごとに区別されています。
• 各不変条件とモデルの重要な遷移を検証するシナリオ（例と反例）が用意されています。
• 明示的な調整なしに、同じデータを複数の所有者が同時に書き込み、不整合を起こすことはありません。
• モデルの決定事項（用語集、不変条件、境界）は、更新されずに古くなる並行コピーを作らず、プロジェクトで承認された唯一の情報源にのみ記録されています。
• 上記のシナリオなしに、モデルを「正しい」と宣言してはいけません。検証済みの反例がないモデルは、検証結果ではなく仮説です。

関連するスキル

• $specsfy-specialist-merge-conflict-resolution は、競合によってモデルの名称や不変条件が影響を受けた場合に、意図を維持します。
• $specsfy-specialist-prototyping は、プロトタイプを規範的な情報源に昇格させずに、ドメインの仮説を検証します。
• $specsfy-specialist-ux-design はユーザージャーニーにおける用語を検証し、$specsfy-specialist-web-api-design は所有権を移転せずに、それを公開契約として提示します。
• 新しい境界づけられたコンテキストによって、サービス、データベース、デプロイの境界が必要になる場合は、$specsfy-specialist-software-architecture を使用します。
• モデルの決定が、外部システムによる同じ概念の定義に依存する場合は、$specsfy-specialist-technical-research を使用します。

モデリング成果物、指針となる質問、DDD とイベントストーミングの一次情報源については、references/standards.md を参照してください。