ddd-master

DDD Master

言語、境界、不変条件を基にドメインモデルを定義または改訂します。新しいモデルの足場を作る前に DDD が適しているかを評価し、既存モデルでは承認済みの判断を再利用します。

変更対象のモデルまたは判断に該当するブランチを使用します。確立済みの言語、コンテキストマップ、タイムラインを再利用します。関連するセクションと、その契約上の依存関係を読みます。契約を切り離せない場合に限り、リファレンス全体を読む必要があります。

同梱ファイルのパス規則

同梱ファイルは、この SKILL.md が置かれているディレクトリを基準に解決します。references/<name> と記述されたパスは、<ddd-master-dir>/references/<name> に展開されます。

ブランチ

タスクの内容…	関連するセクション
DDD の拒否、貧血モデル、トランザクションスクリプト、スローガンだけのフォルダー、CRUD、またはレガシーの書き換え	references/when-not.md：3 つの判定、必然的な複雑さ、またはレガシー
EventStorming、イベントのタイムライン、またはコンテキストが存在する前に何が起きるかを把握すること	references/discovery.md：スキップ／切り替えの判断、形式の種類、エージェントが行うことと偽装すること
ユビキタス言語、サブドメイン、境界づけられたコンテキスト、コンテキストマップ、またはコンテキスト間の関係	references/strategic.md：ユビキタス言語、コンテキストマップ、関係の判断ツリー
集約、値オブジェクト、ドメインイベント、リポジトリ、ファクトリー、または不変条件	references/tactical.md：分類テスト、一貫性境界、および該当する構成要素
ルール密度、リポジトリの FAQ、または Branas／Elemar の実践者チェック	references/practitioner.md：密度、小さな集約、またはリポジトリの FAQ
デフォルトでの CQRS、「DDD」リポジトリのコピー、LLM 生成の集約、またはモデルとコードの乖離	references/pitfalls.md：該当するモデリングまたは生成上の落とし穴

新規または再設計するモデルでは、該当するディスカバリー、戦略、戦術上の判断を順に行います。確立済みのコンテキスト内での限定的な変更では、影響を受ける不変条件と利用側だけが必要です。レイヤー構造への格下げを伴い、構造監査が求められている場合は architectural-analysis を使用できます。

最低基準

1. 新しいコンテキスト境界は組織の知識領域に基づいて定め、局所的な変更には確立済みのマップを再利用します。
2. サブドメイン、境界づけられたコンテキスト、デプロイ可能な単位を、それぞれ別のものとして扱います。
3. 1 つのトランザクションで更新する集約は 1 つです。他の集約は ID として扱います。
4. すべての不変条件をルート、値オブジェクト、またはドメインサービスに配置します。リポジトリメソッドの役割は読み込み、保存、検索に限ります。
5. コマンドが成功した後に、過去形のドメインイベントを登録し、永続化の後に発行します。
6. 言語の変更はモデルの変更として扱います。

ステップ 1：判定

新規または再設計するモデルでは、足場を作る前に分類します。判断に影響する場合は以下の質問を使います。焦点を絞った質問や局所的な修正では、関連する根拠だけで十分です。

1. 必然的な複雑さ（複数の手順にわたる不変条件が同時に変わること）を明記するか、「CRUD ＋構文のみ」と記します。
2. サブドメインをコア、支援、または汎用に分類します。
3. スローガンだけの DDD を特定します。つまり、ルールのモデルが協働によって進化していないのに、Evans の用語やレイヤー別フォルダーだけを使っている状態です。
4. オブジェクトがデータの入れ物で、サービスがルールを所有している場合は、トランザクションスクリプト（またはレコードに対する操作）と名付けます。その設計に DDD のラベルを付けないでください。
5. 変更対象が泥団子の内部にある場合は、Bubble、Autonomous Bubble、または Open-host-over-ACL を選びます。レガシーの書き換えが依頼されている場合は、選択する前に references/when-not.md のレガシーのセクションを読みます。
6. 各ルールを構文、意味、または本番運用に分類します。構文は UI に残してもかまいません。意味と本番運用のルールは、Proceed の場合に限り、モデルの所有者を設ける根拠になります。

「Refuse」、「Downgrade」、または「Proceed」を記録します。

完了条件： アプローチと、その判断に影響する理由が明確であること。モデルに影響する分類だけを記録します。Refuse と Downgrade では、不要な集約型やリポジトリ型の足場を作りません。

ステップ 2：ドメインを把握する

判定が Proceed で、信頼できるイベントタイムラインが存在しない場合に実行します。ユーザーが EventStorming または「何が起こるのか」を尋ねた場合は、references/discovery.md の該当する形式とファシリテーションのセクションを読みます。

1. 質問を把握している人（コード、API、ログ）と、答えを把握している人（名前の分かる人）を列挙します。答えを知る人がいない場合は、ホットスポットにします。
2. 過去形のドメインイベントを、終端のないタイムラインに配置します。文の形の名前を優先します。
3. 時系列に並べ、一度だけ終点から逆向きにたどり、抜けを赤いホットスポットとして示します。
4. 各イベントの直前に、現在形のコマンドとアクターを配置します。原因が不明な場合は、ホットスポットを配置します。
5. 意見の相違を二重に可視化します。お金の流れ、成功指標、欠けている役割について質問し、答えが不明な場合はホットスポットを残します。
6. ユーザーがソフトウェア設計の深掘りを求めていない限り、イベント、コマンド、ホットスポットまでで止めます。黄色のメモは集約の候補であり、そのルールはステップ 4 で扱います。
7. 密結合していないサブドメインの境界を切り出し、関係の種類をステップ 3 に引き継ぎます。

最近の EventStorm、Domain Storytelling、または Example Mapping がすでにある場合は、ワークショップのツールを省略します。タイムラインの成果物は残し、切り出しの段階から続けます。依頼された変更に関係する抜けがある場合に限り、ディスカバリーを再開します。

完了条件： 過去形のイベントが時系列に並んだタイムラインがあり、すべてのイベントにコマンド／アクターまたはホットスポットがあり、関係者一覧または抜けが記載されていること。

ステップ 3：戦略的設計

コンテキスト境界や言語を作成または変更する場合に実行します。コンテキストの図示、言語の固定、関係のマッピングを行う場合は、references/strategic.md の該当する言語またはコンテキストマップのセクションを読みます。

1. 名前の付いた各機能を、コア／支援／汎用に分類します。汎用には、購入または再利用の候補を挙げます。
2. 多義語（Customer、Order、Account）を探します。用語をコンテキストごとに分けるか、名前の付いたコンテキスト内で意味を 1 つに定めます。
3. 生まれつつある各コンテキストについて、ユビキタス言語を確立します。用語集、実際にたどるシナリオ、用語に一致するコード上の名前を定めます。
4. 境界づけられたコンテキストを設計します。デフォルトは、コア 1 つとコンテキスト 1 つです。言語、目的、所有者、用途が異なる場合は分割します。各コンテキストに名前を付けます（その名前は言語の一部になります）。
5. 周囲のコンテキストのコンテキストマップを描きます。各エッジには、方向（上流／下流、相互依存、または自由）と主要なパターンを 1 つ記します。ACL、OHS、順応者、パートナーシップ、共有カーネル、顧客／サプライヤー、公開された言語、別々の道筋、または泥団子のいずれかを選ぶ場合は、references/strategic.md の関係性の判断ツリーを使います。
6. エージェントが所有する各コンテキストについて、必須のキャンバス項目を埋めます。名前、目的、UL 用語、受信または送信メッセージを記載します。

完了条件： 名前の付いた各領域にサブドメインの種類があり、対象範囲内の各コンテキストに名前、目的、境界があり、隣接する各エッジに方向とパターンがあり、必須のキャンバス項目が空欄でないこと。

ステップ 4：1 つの集約を設計する

Domain Model とラベル付けされた境界づけられたコンテキストでのみ実行します。構成要素を設計する際は、該当する場合は整合性と公開の依存関係も含め、references/tactical.md の該当する構成要素のセクションを読んでください。ルールの密度やリポジトリ FAQ を判断する際は、references/practitioner.md の Density または Repository FAQ を読んでください。

1. 集約の名前と存続期間（請求期間、スプリント、またはプロセススコープ）を決めます。
2. 真の不変条件、つまり成功したコマンドの実行後に必ず成り立つルールを列挙します。関係性だけのものや、「Y が存在する場合は X を削除できない」といった誤った不変条件は除外します。
3. 各概念を分類します。変更を通じて同一性を保つもの → エンティティ、属性によって置き換え可能／等価なもの → 値オブジェクト、独自の不変条件とライフサイクルを持つもの → ID で参照する別の集約。
4. 整合性境界を描きます。内側にある各要素はルートと共有する不変条件を明示し、外側の各要素は ID とします。
5. ルートと書き込み API を選びます。コマンドは命令形、イベントは過去形にします。両者を対応づけます。
6. 複数要素にまたがる不変条件はルートに置きます。値オブジェクト／エンティティ内のルールはそれぞれの要素内に置きます。
7. 外部集約はコマンドの実行前にアプリケーションサービス（またはドメインサービス）で読み込みます。集約からリポジトリを開くことはありません。
8. 集約間のルールごとに、トランザクション内で処理するか、結果整合にするかをラベル付けし、担当者を明記します。結果整合の場合はドメインイベントを登録し、後続のトランザクションで別の集約を更新します。
9. サイズと競合を記録します（コマンド頻度 × 同時クライアント数、グラフ／イベントの増加量 × 存続期間）。内側の要素が不変条件を共有しなくなったら分割します。
10. ルートにグローバルな書き込みアクセスが必要な場合は、リポジトリを 1 つにします。リポジトリが受け取るのはこのルートだけとし、クラスター全体を読み込み／保存します。内部の型が漏れる、または不変条件が適用されない構築を防ぐ場合にのみ、ファクトリーを使用します。

完了条件： すべての変更経路がルートを通ること、外部集約が ID であること、各値オブジェクトが不変で構成要素によって等価性が決まること、イベントが過去形で成功後に登録され永続化後に公開されること、リポジトリがある場合はルートだけを受け取ること、リポジトリのメソッドがビジネスルールを持たないこと。

注意すべき落とし穴

• ddd とタグ付けされたパッケージやトピックをモデルとして提示された場合は、ルート上の不変条件と不変の値オブジェクトを確認します。確認できなければ「DDD を名乗るだけ」と記録し、専門家をもとにモデルを作成します。サンプルリポジトリをコピーする場合は、references/pitfalls.md の該当セクションを読んでください。
• 複数ステップのプロンプトがチャット履歴から集約やヘキサゴンを生成しようとしている場合は、用語集／イベント一覧／BC の提案までで止めます。範囲内か不確かなコンテキストの提案は、その集約を生成する前にドメインの根拠と照合し、承認済みの境界を再利用します。ループが LLM による生成の場合は、references/pitfalls.md の該当セクションを読んでください。
• 「DDD を行うため」にイベントストアや新しいマイクロサービスを導入しようとしている場合は、書き込みモデルとデータベースを 1 つずつに保ちます。名前の付いた読み取りが集約の制約によって妨げられる場合にのみ、クエリモデルを分割します。CQRS または Event Sourcing が既定案として提案された場合は、references/pitfalls.md の該当セクションを読んでください。
• *Service が新しい不変条件を持とうとしている場合は、そのルールをエンティティまたは値オブジェクトに置きます。アプリケーションサービスには動詞を使った名前を付けます。
• ヘキサゴナルアーキテクチャのポートを DDD の証拠として選んでいる場合、ヘキサゴナルアーキテクチャとトランザクションスクリプトの組み合わせは有効なダウングレードです。戦術的 DDD では、コンテキスト内にドメインモデルが依然として必要です。