回答:
必要なアーキテクチャの種類によって異なります。
これはOrder
、に基づいて注文の合計価格を返すプロパティ(またはメソッド)があることを意味しOrderLines
ます。またOrder
、メソッドAddOrderItem(Product product, int amount)
を持ち、その特定の製品にOrder
既に存在するかどうかをチェックしOrderLine
ます。
このようなモデルでは、Repository
データにアクセスしたり、Factory
エンティティを作成したりするなど、実際のエンティティではないオブジェクトもあります。これらはドメインサービスと呼ばれます。アプリケーション層は、ドメインサービスの呼び出し(たとえば、データベースからエンティティを取得する)を担当し、エンティティで機能を実行します。Application Layer
可能な限り薄くすべきです。
これは、これらの概念をより詳細に説明するDDDに関する素晴らしい記事です。
Order
価格の計算や重複のチェックなどの動作が含まれますOrderLines
。貧血領域モデルが悪いものであるかどうかについては、さまざまな意見があります。個人的には、実際のドメインモデルを好みます。
この記事では、Anemicドメインモデルと非Anemicドメインモデルの違いについて説明します。
Order
クラス内に配置するにはどうすればよいですか。
エンティティオブジェクトとビジネスオブジェクトはほとんど同じです。たとえば、製品クラスがあり、製品クラスの既存のプロパティを取得して計算を行い、それを公開するプロパティを公開する場合。用語でその罰金、そのプロパティを作成するロジックはクラスに残ります。
さて、あなたのビジネス層クラスに合う場所、という質問が来るかもしれません。私は、ビジネスの問題に対処するためのロジックを持つビジネスレイヤークラスを使用することを好みます。たとえば、Productの例では、ビジネス上の問題として、PayPalなどのサードパーティベンダーを使用してお金を請求することが考えられます。
覚えておくべき重要なことの1つは、エンティティは常にIDを持ちますが、ビジネスオブジェクトはIDのないエンティティであることです。たとえば、製品はエンティティですが、お金にはアイデンティティがありません。お金の1000の異なるインスタンスは同じです。