DDD は初めてですが、現在のプロジェクトに DDD の概念を取り入れようとしています。
私のドメインの多くのエンティティでは、クライアントは特定のワークフローとは関係なく、標準の CRUD 操作をすべて実行する必要があります。私は、UserService や LocationService のような名前のアプリケーション レベルのサービスが多数あることに気づきました。これらのサービスは、それぞれのリポジトリへのファサードとして機能するだけです。
リポジトリ ファサードとしてのこれらのアプリケーション サービスは、アプリケーション サービス パターンの「正しい」アプリケーションですか? それとも、CRUD のみのメソッドをアプリケーション サービスから除外する必要がありますか? もしそうなら、インターフェース層にリポジトリファサードが必要ですか?
もちろん、これはアプリケーションに依存し、より直接的なアプローチを選択してリポジトリをクライアントに直接公開する場合は、好みの問題になる可能性もあります。このアプローチの利点の 1 つは単純さです。コードの実行を追跡するためにレイヤーをトラバースしているわけではありません。一方、アプリケーション サービスの役割は、ドメイン層のファサードまたは API の役割です。
つまり、アプリケーション サービスはドメイン層をカプセル化し、ドメイン ロジックの実行を調整します。このトークンにより、リポジトリはアプリケーション サービスによってカプセル化することもできます。この場合の利点は、ドメイン層のすべてのクライアントが、コマンドを発行しているかデータを取得しているかにかかわらず、アプリケーション サービスを介して対話するという一貫性です。
最適なソリューションは、アプリケーションによって異なります。必要な機能のすべてが CRUD または大部分が CRUD である場合、アプリケーション サービス (または本格的な DDD) は必要ありません。この場合、すべてのサービスはリポジトリへの委任であるため、不要な複雑さが追加されます。ただし、アプリケーション サービスは、リポジトリが処理する必要のないトランザクションと作業単位を管理するための便利なジャンクションにもなります。
別の方法として、この責任をホスティング環境のインフラストラクチャ (ASP.NET MVC アプリケーションのアクション フィルターなど) に委任することもできます。
ドメインで CRUD スタイルのユース ケースが必要な場合は、それで問題ありません。
私の意見では、リポジトリを直接公開するのは間違っていると思います。なぜなら、アプリケーション サービスの責任には機能的なユース ケース以上のものがあるからです。つまり、トランザクション制御、セキュリティ、および基本的な入力検証です。
アプリケーションサービスのメソッドには、ユースケースを表す名前を付ける必要があります。DDDでは、CRUDを避けるべきだとよく言われますが、私の経験では、プロダクトオーナー/ドメインの専門家は、エンティティの「作成」または「追加」、「更新」、「編集」、「修正」の観点から話すことがよくあります。およびエンティティ。それらがあなたが実装することを任されたユースケースであるならば、それらは確かにあなたのアプリケーション層にあるでしょう。
プロダクトオーナーがCRUDを反映する用語で話している場合はそこにあるはずですが、CRUDを反映していない用語で話している場合は、それを避ける必要があります。