web-dev-qa-db-ja.com

アーキテクチャ：コントローラー、サービス、リポジトリ間でモデルを渡す方法

すべてのドメインモデルを含むドメインプロジェクト、サービスとインフラストラクチャを含むインフラストラクチャプロジェクト、リポジトリとエンティティを含むアーキテクチャを構築しようとしています。

ただし、さまざまなレイヤー間でオブジェクトを渡すための最良の方法については少し混乱しています。

プレゼンテーション層は、ドメインとサービス層/インフラストラクチャのみを認識し、ドメインオブジェクトをサービスに渡します。そして、それは私が疑うところです。

私が持っているとしましょう：

  • DomainProduct
  • EntityProduct
  • ProductController
  • ProductService
  • ProductRepository

質問：ドメインモデルとエンティティの間でオブジェクトをどこにマッピングしますか？ドメインモデルを使用してサービスを呼び出しますが、サービスはドメインモデルを使用してリポジトリを呼び出しますか、それともエンティティにマッピングしてそれを使用してリポジトリを呼び出しますか？

  1. コントローラ->ドメインモデル->サービス
  2. サービス->ドメインモデル->リポジトリ

または：

  1. サービス->エンティティ->リポジトリ

（およびその逆）

ケース：製品の削除

ここでは、削除する必要がある製品のIDを使用して、コントローラーからサービスを呼び出すだけです。次に、サービスは次のいずれかです。

  • リポジトリでDelete（id）を呼び出す

または

  • IDによってリポジトリから製品を取得します
  • モデルでリポジトリの削除メソッドを呼び出しますか？

しかし、それはDDDの乱れではありませんか？最初にサービスレイヤーからDomainProductを取得してから、そのDomainProductでDeleteを呼び出す必要がありますか？それは不必要に冗長に見えるだけです。

それがどのように最良に行われるかについて少し混乱しています。私はIDが一番好きで、サービスとリポジトリの間でエンティティを渡すことが好きです。しかし、それは違反だと思います。

手伝って頂けますか？

c#domain-driven-designentity-frameworkormonion-architecture
3
Trolley

CQRSパターンを見ると、ドメイン操作がコマンドに要約されていることがわかります。この場合、IDを要求するだけで削除コマンドを定義することは完全に問題ないと思います。また、このパターンを使用すると、データの表現方法に完全な柔軟性が与えられ、ドメインエンティティの構造に結び付けられなくなります。

次に、ドメインに対する操作でドメインの削除が必要になる場合があります。メールキューがあり、アイテムが送信しきい値に達したとします。次に、しきい値に達したかどうかを確認して、オブジェクトをリポジトリに提供し、その方法でオブジェクトを削除することができると主張できます。

私がうんざりしていることの1つは、コントローラーがドメインオブジェクトに直接アクセスできるようにすることです。ビジネス層と適切に通信できます。

1
Cyberwiz

理想的には、separateドメインモデルandデータ転送オブジェクト（DTO）があります。ドメインモデルは、レイヤーごとのモデルまたはdomainです。たとえば、UIレイヤーとビジネスロジックレイヤーには、独自のドメインオブジェクトが必要です。

DTOを使用して、レイヤー間で「データ」を渡します。

[UI Layer] <- UserDto -> [Business logic layer]

ドメインオブジェクトをDTOに変換し、反対側で再び戻すことは、一般に「オブジェクトマッピング」と呼ばれます。 AutoMapperなどのライブラリは、プロセスを簡略化するために使用されます。

0
user9993