ddd-review

1 行での概要

対象のファイル、差分、またはモジュールを DDD のアンチパターンチェックリストに照らして確認し、重大度、該当箇所、修正の方向性とともに違反を報告します。

このスキルを使う場面

• DDD の観点で行うプルリクエスト形式のレビュー（「これは DDD に沿っていますか？」「この集約をレビューしてください」など）。
• モデルの劣化が疑われる特定のモジュール。
• 急いで作成し、これから堅牢化するコード。
• ドメインモデルをチームメイトに説明する場面――「現在のコードのどこに問題がありますか？」

このスキルを使わない場面

• ユーザーが新しいコードを求めている場合 → ddd-implement に誘導します。
• ユーザーがゼロからの再設計を求めている場合 → ddd-design に誘導します。
• ユーザーが目指す形をすでに把握しており、そこに至る手順を求めている場合 → ddd-refactor に誘導します。

主な内容

対象のコードを 6 項目でチェックします。各指摘について、重大度（blocker / major / minor）、該当箇所、修正方法を説明するパターンスキルを報告します。

1. ユビキタス言語を使っていますか？ クラス名とメソッド名には CRUD（createX、updateY）や技術用語（Manager、Helper）ではなく、ビジネス上の名詞と動詞を使うべきです。データベーステーブルのように読めるモデルは要注意です。

2. 集約の境界を守っていますか？ 集約が他の集約を参照する場合は、オブジェクト参照ではなく ID のみを使います。class Order { val customer: Customer } というフィールドは、ほぼ間違いなく blocker レベルの指摘事項です。

3. 貧血モデルのチェック。 振る舞いはどこにありますか？ すべてが *Service クラスにあり、エンティティがフィールドとゲッターだけなら、そのエンティティは貧血モデルです。振る舞いをエンティティ／集約ルートに移します。

4. プリミティブ型への固執。 String customerId、Long amount、String email を探します。それぞれ、値オブジェクトにすべきものが見落とされています。重大度は、そのプリミティブ型がメソッドシグネチャを通過する頻度に応じて高くなります。

5. リポジトリの漏出。 ドメインコードは JPA、JDBC、HTTP クライアント、フレームワークの型をインポートすべきではありません。ドメイン層に EntityManager、Predicate、ResultSet が登場する場合、抽象化が漏れています。

6. ファクトリーかコンストラクターか。 コンストラクターが 9 個のパラメーターを受け取る場合や、かなりの処理を行う場合は、ファクトリーが隠れています。逆に、単一のメソッド create(...) を持つ FooFactory が、コンストラクターでできること以上を何もしていない場合は、過剰設計です。

判断の指針

• 意見ではなく、指摘事項を報告します。各指摘には行の範囲とパターンスキルを明記します。
• 重大度：blocker（モデルが誤っており、他のコードを誤解させる）、major（実際に問題のある兆候であり、早めのリファクタリングが必要）、minor（スタイルや命名に関するもので、ついでに修正できる）。
• 違反を示さずにパターン名を挙げないでください。「これは貧血モデルです」は指摘事項ではありません。「Order エンティティには 14 個のフィールドがあり、それらを変更するメソッドが 1 つもありません。状態変更はすべて OrderService.process() が行っています」というのが指摘事項です。

アンチパターン

• カタログに明らかに違反するコードに対して、「問題ありません」とお墨付きを与えること。
• モデルではなくスタイルをレビューすること――括弧の配置は DDD の関心事ではありません。
• コードの参照箇所を示さずにパターンを挙げること。
• 長いファイルをすべて問題視すること――長さだけでは違反になりません。

関連項目

• ddd-anti-patterns — このスキルが照合するカタログです。
• ddd-core のすべてのパターンスキル — 指摘では関連するスキルを挙げます。

参考資料

• Evans, Domain-Driven Design（2003）、第 4 章（ドメインの隔離）、第 5～6 章（構成要素）、第 III 部（より深い洞察につながる兆候）。