0

ここに私のシナリオがあります、

製品カタログと製品提供可能性に関するルールを備えた別のシステムから製品を取得するための注文アプリケーションを開発しています。私たちはウェブサービスを通じて彼らと通信します。

製品を取得するためのサービス リクエストの作成には、住所、顧客プロファイル、マーケティング戦略ルールなどの他のエンティティを参照する必要があるビジネス ロジックがさらに含まれます。

製品エンティティを設定するために製品リポジトリ内で呼び出しを行うことを考えている場合、他のエンティティを参照し、製品リポジトリ内にそのような複雑なロジックを持つことは適切ですか?

それらのいくつかは Application Service を使用することを提案していますが、特定のタスクを完了するためにアプリケーションサービスがドメインおよびインフラストラクチャと対話することを理解しているため、明確ではありません。また、ビジネスロジックは保持されません。

これを行う適切な場所と最良の方法は何ですか?

4

3 に答える 3

1

ドメイン サービスを使用し、webservice を呼び出すアダプターで実装することをお勧めします。

リポジトリ戦略とは、順序が制限されたコンテキストで製品を集約として持つ必要があることを意味します。しかし、製品カテゴリと価格設定は、限定されたコンテキストを注文する際のコア ドメインではありません。したがって、製品を集合体として必要としない場合があります。どの製品が予約されているかを集計するには、いくつかの単純な値オブジェクトが必要だと思います。他の製品のものをドメイン サービスの背後に隠します。

良い例は、eric evans の DDD 本で言及されている cargo RoutingService です。

于 2013-09-19T00:57:45.830 に答える
0

DDD によると、リポジトリにはビジネス ロジックを含めることはできません。これらは、ドメイン レイヤーが永続化されたデータにアクセスして操作するためのシンプルなツールである必要があります。すべてのビジネス ロジックは、ドメイン サービス、集計、エンティティ、または値オブジェクトによって保持される必要があります。

これはすべての DDD マニュアルに非常に明確に書かれているため、敬意を表して、それらを (再) 読むことをお勧めします。

幸運を!

于 2013-09-18T18:03:33.953 に答える