エンティティまたはビジネスレイヤーに計算ロジックを配置する必要がありますか？

最近、エンティティ層に単純な計算を配置するのか、それとも生データを保存して計算ロジックをビジネス層に残すだけのエンティティにするのかという質問に直面しました。

私の質問は、エンティティクラスのプロパティに単純な計算をカプセル化することが賢明かどうかです。

必要なアーキテクチャの種類によって異なります。

• ドメイン駆動設計では、データと機能の両方を持つドメインモデルを作成します。

これはOrder、に基づいて注文の合計価格を返すプロパティ（またはメソッド）があることを意味しOrderLinesます。またOrder、メソッドAddOrderItem(Product product, int amount)を持ち、その特定の製品にOrder既に存在するかどうかをチェックしOrderLineます。

このようなモデルでは、Repositoryデータにアクセスしたり、Factoryエンティティを作成したりするなど、実際のエンティティではないオブジェクトもあります。これらはドメインサービスと呼ばれます。アプリケーション層は、ドメインサービスの呼び出し（たとえば、データベースからエンティティを取得する）を担当し、エンティティで機能を実行します。Application Layer可能な限り薄くすべきです。

これは、これらの概念をより詳細に説明するDDDに関する素晴らしい記事です。

• Anemic Domain Modelも使用できます。つまり、エンティティはget / setプロパティで構成され、動作は含まれません。このような設計では、ビジネスレイヤーにOrder価格の計算や重複のチェックなどの動作が含まれますOrderLines。

貧血領域モデルが悪いものであるかどうかについては、さまざまな意見があります。個人的には、実際のドメインモデルを好みます。

この記事では、Anemicドメインモデルと非Anemicドメインモデルの違いについて説明します。

エンティティオブジェクトとビジネスオブジェクトはほとんど同じです。たとえば、製品クラスがあり、製品クラスの既存のプロパティを取得して計算を行い、それを公開するプロパティを公開する場合。用語でその罰金、そのプロパティを作成するロジックはクラスに残ります。

さて、あなたのビジネス層クラスに合う場所、という質問が来るかもしれません。私は、ビジネスの問題に対処するためのロジックを持つビジネスレイヤークラスを使用することを好みます。たとえば、Productの例では、ビジネス上の問題として、PayPalなどのサードパーティベンダーを使用してお金を請求することが考えられます。

覚えておくべき重要なことの1つは、エンティティは常にIDを持ちますが、ビジネスオブジェクトはIDのないエンティティであることです。たとえば、製品はエンティティですが、お金にはアイデンティティがありません。お金の1000の異なるインスタンスは同じです。