ddd-repository

1 行の概要

リポジトリは、集約をメモリ内コレクションとして扱うかのように見せることで、永続化の仕組みを隠します。ドメインコードは、ストレージが SQL、キー・バリュー、メモリ内のいずれであるかを知りません。

このスキルを使う場面

• 識別子を使って集約を読み込んだり保存したりする場合。
• 永続化の型をドメインに漏らす、その場しのぎの DAO を置き換える場合。
• ドメインの意味に沿った少数のクエリ（findByStatusEqualsAndCustomerIdEquals ではなく findActiveByCustomer）を定義する場合。

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

• 値オブジェクト。検索の基準となる識別子がありません。
• 表示目的で集約をまたいでクエリする場合。リポジトリメソッドではなく、読み取りモデルを構築してください。
• レポートや分析。これらには、読み取りに最適化されたクエリレイヤーが必要であり、ドメインリポジトリには適しません。

主な内容

リポジトリは、1 つの集約ルートを対象とします。そのインターフェースはドメイン層に置き、実装はインフラストラクチャ層に置きます。ドメインコードはインターフェースのみに依存し、インフラストラクチャコードが実装をつなぎます。

インターフェースでは、ユビキタス言語を使います。メソッド名は、永続化の仕組みではなく、ビジネスで何を行うかに基づいて付けます。findActiveByCustomer は適切です。findByStatusEqualsAndCustomerIdEquals はドメインの形をしたラッパーに SQL クエリ名を持ち込んでおり、抽象化から実装が漏れています。

リポジトリが扱うのは、集約全体です。集約の一部や内部エンティティ、データベースの行を返すことはありません。返すのは集約ルートであり、呼び出し側はそれを通じて操作します。

クエリが表示を目的とする場合、つまりユーザーに注文一覧を見せる、顧客のアクティビティを要約する、ダッシュボードを作成するといった場合は、通常、リポジトリに含めるべきではありません。ビューに合わせて最適化された、独自のクエリインターフェースを持つ読み取りモデルを別途構築してください。

判断のヒント

• 集約ルートごとにリポジトリを 1 つ設けます。エンティティごとではありません。
• メソッドが永続化の型（JPA における Query、Predicate、Specification、EntityManager）を公開する場合は、抽象化から実装が漏れています。それらを下位レイヤーに移してください。
• メソッドが行、DTO、または部分的なエンティティを返す場合、ドメインリポジトリの操作ではありません。読み取りモデルに移してください。
• リポジトリのメソッド数が約 5～8 個を超える場合は、その中に実際は読み取りモデルのクエリであるものが含まれていないか検討してください。

アンチパターン

• 行、DTO、永続化の型を返すリポジトリ。
• エンティティごとにリポジトリを設け、集約の内部を公開すること。
• 少数の名前付きのドメインに沿ったメソッドではなく、任意の検索メソッド（findByXAndYAndZAndW）を使うこと。
• フレームワークの汎用 JpaRepository / CrudRepository をドメインリポジトリとして使うこと。これは CRUD 操作を無差別にすべて公開し、ドメインを JPA に結び付けます。

関連項目

• ddd-aggregate — リポジトリが扱う対象について。
• ddd-factory — 集約の作成について。リポジトリは永続化された集約のライフサイクルを扱います。
• ddd-anti-patterns — 実装が漏れるリポジトリや CRUD 名のメソッドについて。

参考資料

• Evans, Domain-Driven Design（2003 年）、第 6 章（ドメインオブジェクトのライフサイクル）。