repository-placement

リポジトリインターフェースの配置

結論

リポジトリインターフェースはユースケース層に置く。ドメイン層には置かない。

なぜドメイン層に置くと問題か

物理的な近さが結合を誘発する

同じ層にあると、ドメインモデルがリポジトリを使いやすくなる：

// ❌ 集約の中でリポジトリを使ってしまう
class Order {
  Order withRelatedOrder(OrderId relatedId, OrderRepository repo) {
    Order related = repo.findById(relatedId);  // ← 同じ層にあるから気軽に使える
    return this.withAddedRelatedOrder(related);
  }
}

// ❌ ドメインサービスがリポジトリだらけになる
class OrderDomainService {
  private OrderRepository orderRepo;
  private CustomerRepository customerRepo;
  private ProductRepository productRepo;
  private InventoryRepository inventoryRepo;
  // リポジトリの注入が増え続ける
}

ドメインが「永続化」を知ってしまう

// ドメイン層にこれがあるということは...
interface OrderRepository {
  void save(Order order);      // ← 「保存」という概念を知っている
  Order findById(OrderId id);  // ← 「取得」という概念を知っている
}

ドメインモデルは純粋なビジネスルールだけを持つべき。

ユースケース層に置く利点

構造が設計意図を強制する

[ドメイン層]              ← リポジトリをimportできない = 結合しない
     ↑
[ユースケース層]          ← リポジトリインターフェース定義（出力ポート）
     ↑
[インターフェースアダプタ層] ← リポジトリ実装（入力/出力アダプタ）

物理的な距離がガードレールになる：

• ドメインモデルからimportしにくい（別パッケージ/モジュール）
• 「リポジトリはユースケース層のポート」という意図が構造で伝わる
• 集約がIDで参照するルールを守りやすい

集約のID参照ルールを自然に守れる

// ✅ 集約は他の集約をIDで参照
class Order {
  private final CustomerId customerId;  // Customer実体ではなくID
  private final List<ProductId> productIds;
}

// ユースケース層でリポジトリを使って解決
class PlaceOrderUseCase {
  private OrderRepository orderRepo;
  private CustomerRepository customerRepo;

  void execute(PlaceOrderCommand cmd) {
    Customer customer = customerRepo.findById(cmd.customerId);
    // ユースケース層で必要なエンティティを取得
  }
}

検出パターン

ドメイン層にリポジトリがある兆候

domain/
  order/
    Order.java
    OrderRepository.java  ← ❌ ここにある

インターフェースアダプタ層にリポジトリインターフェースがある兆候

interface-adapters/
  repositories/
    OrderRepository.java  ← ❌ ここにある

正しい配置

domain/
  order/
    Order.java
    OrderId.java

usecases/  (または application/, interactor/)
  order/
    OrderRepository.java      ← インターフェース定義

interface-adapters/  (または adapters/, infra/)
  repositories/
    JpaOrderRepository.java   ← 実装