DDDは初めてのことですが、DDDの概念を現在のプロジェクトに組み込もうとしています。DDDアプリケーションサービスのCRUD？
ドメイン内の多くのエンティティでは、クライアントは特定のワークフローとは関係なく、すべての標準CRUD操作を実行する必要があります。私は、それぞれのリポジトリのファサードとして機能するだけでなく、UserServiceやLocationServiceなどの名前を持つ多数のアプリケーションレベルサービスで自分自身を見つけています。
これらのアプリケーションサービスは、リポジトリファサードとして、アプリケーションサービスパターンの「正しい」アプリケーションですか？ CRUD専用のメソッドはアプリケーションサービスから離れるべきですか？もしそうなら、インタフェース層にレポジトリファサードがあるはずですか？
これはもちろんアプリケーションに依存し、より直接的なアプローチを選択してクライアントに直接リポジトリを公開する場合もあります。このアプローチの利点の1つは簡単です。あなたは、コードの実行を追跡するためにレイヤーをトラバースしません。一方、アプリケーションサービスの役割は、ドメイン層のファサードやAPIの役割です。
つまり、アプリケーションサービスはドメインレイヤをカプセル化し、ドメインロジックの実行を調整します。このトークンによって、アプリケーションサービスによってリポジトリをカプセル化することもできます。この場合の利点は、ドメイン層のすべてのクライアントがコマンドを発行しているかデータを取得しているかに関わらず、アプリケーションサービスを通じてドメイン層のすべてのクライアントが対話するという点で一貫性があります。
最適な解決策は、アプリケーションによって異なります。必要な機能がすべてCRUDまたはほとんどCRUDの場合、アプリケーションサービスは必要ありません（この点については本格的なDDD）。この場合、すべてのサービスがリポジトリに委任され、不要な複雑さが増すためです。ただし、アプリケーション・サービスは、リポジトリーが処理する必要のないトランザクションおよび作業単位を管理するための便利な分岐点になることもあります。
代わりに、この責任をASP.NET MVCアプリケーションのアクションフィルタなど、ホスティング環境のインフラストラクチャに委任することもできます。
あなたのアプリケーションサービスのメソッドは、ユースケースを表す名前を持つ必要があります。 DDDではCRUDを避けるべきだと言われていますが、私の経験では、製品の所有者/ドメインの専門家はしばしば、エンティティの「作成」や「追加」、「更新」、「編集」、およびエンティティ。それらがユースケースであれば、実装することを任されています。あなたは必ずアプリケーションレイヤーに入ります。
製品の所有者がCRUDを反映していると言えば、CRUDが反映されていると言えますが、CRUDを反映しない言葉で話している場合は、回避する必要があります。
ドメインにCRUDスタイルのユースケースが必要な場合は、正しいです。
私の意見では、リポジトリを直接公開するのは間違いでしょう。なぜなら、アプリケーションサービスの責任には、機能的なユースケースの「単なる」以上のものが含まれているからです。トランザクション制御、セキュリティー、および基本入力の妥当性検査です。
段落を使用してください、それはテキストをもっと読みやすくします。 – jgauffin
申し訳ありません！ – eulerfx
を使用するケースがCRUDyで、クライアントがリポジトリを直接呼び出す場合は、repositoryImplがトランザクションを処理しないようにしてください。 – redzedi