ddd-implement

1 行での概要

DDD パターンの選択を具体的なコードにつなげるため、命名と不変条件を明確にしてから、言語アダプターのスキルに引き継ぎます。

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

• ユーザーが使用したいパターン（エンティティ、値オブジェクト、集約、ドメインイベント、リポジトリ、ファクトリー）をすでに把握している場合。
• 対象言語がわかっている（またはプロジェクトから推測できる）場合。
• ユーザーが説明文だけではなく、慣用的なスキャフォールディングを求めている場合。

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

• ユーザーがまだ設計中の場合 → ddd-design に誘導します。
• ユーザーがコードを動作させているものの、コードスメルがある場合 → ddd-refactor に誘導します。
• ユーザーが既存コードへの批評を求めている場合 → ddd-review に誘導します。

主な内容

順番に 3 つのステップを実施します。ステップ 2 は省略しないでください。

ステップ 1 — パターンを確認する。 エンティティ、値オブジェクト、集約ルート、ドメインサービス、ドメインイベント、リポジトリ、ファクトリーのいずれかを明示します。ユーザーが決めかねている場合は質問し、判断基準に合ったパターンのスキルに誘導します。

ステップ 2 — 不変条件とユビキタス言語の名前を確認する。 常に満たされるべき条件は何ですか？ビジネスでは何と呼ばれていますか？不変条件が強制されていないエンティティは単なる構造体であり、名前が適切でない値オブジェクトは概念を捉え損ねています。ユーザーが「後で考えます」と答えた場合は、異議を唱えてください。不変条件は TODO ではなく、コンストラクターまたはファクトリーに含める必要があります。

ステップ 3 — 言語アダプターに引き継ぐ。 プロジェクトから対象言語を検出します。プロジェクトが Kotlin の場合は、ddd-kotlin-idioms に誘導します。検出された言語用のアダプターがない場合は、該当するパターンスキルに従った疑似コードを作成し、ユーザーがアダプターを作成できるよう、その不足を伝えます。

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

• 不変条件が指定されていない場合は中断します。フィールドとゲッターを生成するのはユーザーのためにならず、貧血コードを DDD に見せかけることになります。
• 言語にかかわらず、値オブジェクトには不変性を、エンティティには ID のみで判定する等価性を優先します。アダプタースキルが各言語の慣用的な方法でこれを適用します。
• リポジトリはドメイン層のインターフェースであり、実装はインフラストラクチャ層に置きます。アダプターが、その言語の慣習に沿った適切な配置を行います。

アンチパターン

• 振る舞いのないゲッターとセッターを生成する。
• アノテーション以外に何もない JPA @Entity を、「DDD」のエンティティとして作成する。
• 「アプリケーション層で検証する」ために、不変条件の強制を省略する。
• エンティティに言語のデータクラス相当のものを使用する（ID が属性の等価性に置き換わる）。

関連項目

• ddd-entity、ddd-value-object、ddd-aggregate、ddd-domain-event、ddd-repository、ddd-factory — このスキルが実現するパターンの基本要素。
• ddd-kotlin-idioms — コード出力用の Kotlin アダプター。

参考文献

• Evans, Domain-Driven Design（2003 年）、第 5〜6 章。