domain-driven-design - ドメイン モデル オブジェクトには何が入り、サービスには何が入りますか?

Question

貧血のないドメイン モデルを目指すドメイン駆動設計では、ドメイン オブジェクトとサービス指向メソッドのどちらに実装するかをどのように決定しますか?

編集：私は例を使ってこれを別の方法で尋ねましたが、ここでより良い答えを得ました

Answer 1

DDD の考え方は、ドメイン モデルにデータとほとんどのビジネス ロジックが含まれているということです。サービスは通常、これらの構造の永続性を扱います。

次に、ドメイン オブジェクトを常に変更/修正する複数のステップでビジネス プロセスが構成される中間のケースがあります。通常、サービスを使用して何らかのプロセスを実現しています。したがって、通常は、サービスからの結果でドメイン オブジェクトを更新します。ドメイン オブジェクトの実装がサービスを自分で呼び出すことは決してありません。

したがって、次のようなコードがよく見られます。

if (order.isValidForPurchase() && orderValidatorService.isValidOrder( order))
    orderService.order( order)

単純に、一部の真実は注文オブジェクトに知られており、一部は に知られている外部データを必要とするためorderValidatorServiceです。おそらく、これら 2 行のコードもorderService.orderメソッド内にある可能性があります。

これらのプロセスにいくつのドメイン オブジェクトが存在するかを調査することは常に価値があると思います。当初考えていたよりも多くの概念を作成することで、多くのことが得られる場合があります。これは実際には、ビジネス プロセスの状態とオブジェクト モデルの交差点です。多くの場合、DDD モデルは過度に構造的な観点からドメインを捉えようとする傾向があり、IMO はコア プロセスを無視しすぎています。Orderだから、あまりにも構造的すぎる人は、オブジェクトを作ると思います。プロセスを追加するShoppingCartOrderと、UnshippedOrder、 、ShippedOrder、BilledOrderおよびHistoricalOrder. これにより、サービスの統合が簡単になる場合もあります。