ddd-design

1 行の概要

機能の概要からドメインモデルの草案までユーザーを導きます。ユビキタス言語 → 境界づけられたコンテキスト → 集約 → 主要なイベントの順に進めます。

このスキルを使用する場面

• まだモデルがない新機能。
• ドメインレイヤーを立ち上げる新規プロジェクト。
• 既存システムを、まだモデルのない新しいビジネス領域へ拡張する場合。
• ユーザーが明示的にドメインの「設計」、「モデル化」、「アーキテクチャ設計」を依頼した場合。

このスキルを使用しない場面

• すでに決定済みのパターンに基づくコード生成 → ddd-implement に案内します。
• 既存コードの変換 → ddd-refactor に案内します。
• DDD 違反についてのコード監査 → ddd-review に案内します。

主な内容

設計は 4 つのステップで進めます。価値の大半は最初の 2 ステップにあり、残りの 2 ステップは言語と境界が明確になってから進めます。

ステップ 1 — ユビキタス言語を引き出す。 ユーザー（またはドメインエキスパート）に、機能について自分の言葉で説明してもらいます。名詞と動詞を一言一句そのまま記録します。技術用語に聞こえる用語（「エンティティ」、「レコード」、「DTO」）や、意味が多義的な英単語には異議を唱えます。詳しくは ddd-ubiquitous-language を参照してください。

ステップ 2 — 境界づけられたコンテキストの概要を描く。 このモデルの範囲はどこまでですか？ このモデルが責任を負わないのはどのモデルですか？ 上流と下流のコンテキストに名前を付けます。詳しくは ddd-bounded-context を、コンテキスト間の関係については ddd-context-mapping を参照してください。

ステップ 3 — 集約を特定する。 記録した名詞から、トランザクション上、一緒に変更されるものをグループ化します。各クラスターにはルートが 1 つあり、外部のコードはルートだけを参照します。詳しくは ddd-aggregate を参照してください。

ステップ 4 — ドメインイベントの候補に名前を付ける。 ビジネスにとって重要な、過去形で表現される出来事です（OrderPlaced、RefundIssued）。これらは集約やコンテキスト間の境界を明らかにします。詳しくは ddd-domain-event を参照してください。

判断のヒューリスティクス

• 会話の約 80% を言語と境界（ステップ 1〜2）に費やします。後になってモデルが間違っていると感じる場合、その原因はほぼ常にステップ 1 を急いだことにあります。
• ユーザーが物事に正確な名前を付けることに抵抗するなら、それこそが取り組むべき作業です。丁寧に異議を唱えましょう。
• 概要の作成で止めます。このスキルではコードを作成しません。ユーザーから依頼されたら ddd-implement に引き継ぎます。

アンチパターン

• 言語が定まる前に、エンティティや属性の検討に飛びつく。
• 「とりあえずすべてを 1 つの大きなコンテキストにまとめる」— 今の会話は短く済みますが、後でコンテキストの分割が必要になります。
• データベーススキーマの設計を並行して進める — スキーマ思考によってモデルが損なわれます。
• 動詞が 1 つも出ていないうちにクラス図を作成する。

関連項目

• ddd-ubiquitous-language — すべての設計セッションで最初に作成する成果物。
• ddd-bounded-context — モデルの範囲。
• ddd-context-mapping — 隣接するモデルとの関係。
• ddd-aggregate — トランザクション上の一貫性に基づくエンティティのグループ化。
• ddd-domain-event — 集約とコンテキストをつなぐ境界。
• ddd-subdomain-classification — そもそも深くモデル化する価値があるかどうか。

参考文献

• Evans, Domain-Driven Design（2003 年）、第 I 部（第 1〜3 章）および第 IV 部（第 14〜15 章）。