貧血ドメインモデルとドメインサービス

Question

ドメインエンティティが貧血ではない場合、特定の使用法を内部に埋め込むため、特定のドメインサービスを使用/構築する必要がありますか？エンティティの内部に入るべきかどうかの検証はどうですか？

ユニットテストにはどのように柔軟性がありますか？

ありがとうございます！

Answer 1

を通常時に貧血をモデルが使用されていない場合、ドメイン固有のサービスを必要とするニーズがあります。なぜなら、非貧血モデル（またはもしかしたらモデル）は、自分自身を操作できるコードを含むべきですが、他のモデル、特に親子関係を通して直接関連しないモデルに依存することを控えるべきです。

分離ドメインサービスを使用すると、分離されたドメインを維持し、豊富な機能を提供することができます。ドメインサービスは、ドメインモデル全体のより大きなビューを潜在的に認識できるためです。

検証に関しては、これらのモデルが独自の検証を提供することは珍しいことではありませんが、モデルの有効な状態はモデルが認識できない大きなコンテキストに依存することがあることを忘れないでください。まだ存在するだろう。

最後に、ユニットテストの柔軟性は、アプリケーションとその基盤技術（言語の選択など）にかなり依存します。どちらのアプローチでも単体テストに十分な影響があるケースはほとんど見られませんでした。

Answer 2

Domain Servicesは、エンティティの一部ではない機能があるため、ドメインモデルを使用する場合に必要です。

たとえば、RepositoryまたはFactoryと考えてください。 RepositoryのインターフェースはおそらくDomain Layerにありますが、実装はInfrastructure Layerになります。 Factoryでは、実装とインターフェースの両方がDomain Layerにあります。

これらのドメインサービスは、アプリケーションレイヤーから使用されます。アプリケーション層の目標は、ドメインモデルが自分の仕事を行うためにすべてが適切に行われていることを確認することです。これは、リポジトリから特定のエンティティを読み込んで、ドメイン固有の関数を呼び出すことを意味します。

検証はエンティティ内に行う必要があります。たとえば、Moneyクラスがあるとします。

public class Money 
{ 
    public Money(string currency, int amount) 
    { 
     Currency = currency; 
     Amount = amount; 
    } 

    public int Amount { get; set; } 

    public string Currency { get; set; } 
} 

Moneyクラスは、あなたがこれを検証するでしょう負の量を、持つことを許されていない場合は？

これを実行する最適な場所は、クラス内です。エンティティは、自身の状態を担当します。 Moneyクラスで が、これは統合されるべき重複OrderLine項目がある場合Orderチェックする責任があるOrderLinesとOrderクラスで見やすいが、例えばある（輸送費を節約できます！）

Answer 3

ドメインサービスには通常、自分のエンティティの1つに当てはまらないドメイン機能が含まれています。これは多くの他のドメインオブジェクトに必要な機能であることが多く、ドメインサービスを多くのオブジェクトが接続する大きなネクサスにする可能性があります。検証用として

、それはあなたが検証したいときや内容に応じてさまざまな場所で使用できます

• 工場は、エンティティの作成時に不変条件を強制

• 集計のルーツは、その懸念不変条件を施行します全体の集計

• 基本的な検証もしばしば実体そのもの

内で行われます

• アプリケーションの現在の状態に関連するデータを必要とするカスタム検証を行うことができます。この場合、検証はアプリケーション層で実行される可能性が高くなります。