レイヤードアーキテクチャのRepositoryはドメインモデルのインタフェースに依存する

koushisa.icon

これだけだと具体性を欠くため、引用元からさらに深掘りした

ドメイン層: ビジネスロジックの核心部分で、エンティティや値オブジェクト、ドメインサービスなどがこの層に位置する。

インフラストラクチャ層: データベースへのアクセスや外部APIとの通信など、技術的な詳細を担当する層。

Repositoryとドメインモデルの関係

Repository: インフラストラクチャ層に位置するが、ドメイン層のエンティティやアグリゲートを扱うためのインターフェースを提供します。このインターフェースはドメイン層で定義され、インフラストラクチャ層で具体的な実装が行われます。

ドメインモデル: ドメイン層に位置するエンティティや値オブジェクトなどのオブジェクト。ビジネスロジックの核心部分を担当します。

具体例

考えられる具体例として、オンライン書店のシステムを想定します。

ドメインモデル: Book エンティティが存在し、それに関連する属性やビジネスロジック（例: 割引価格の計算）が定義されている。

Repository: BookRepository インターフェースがドメイン層で定義されており、以下のようなメソッドが存在するかもしれません。

findById(bookId: ID): Book

findAll(): List<Book>

save(book: Book): void

このBookRepositoryの具体的な実装（例: データベースへのアクセスロジック）はインフラストラクチャ層で行われますが、実装はBookエンティティに依存しています。

このように、レイヤードアーキテクチャにおけるRepositoryはドメインモデルに依存する設計が一般的です。これにより、ビジネスロジックの核心部分とデータアクセスのロジックが分離され、変更や拡張が容易になります。