1

If domain entities aren't anemic, so they embed specific-usage behavior inside themselfes, is there a need/point to use/build specific domain services? How about validation should it go inside an entity?

What way is more flexible for unit testing?

Thanks!

4

3 に答える 3

6

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

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

検証に関しては、これらのモデルが独自の検証を提供することは珍しくありません。モデルの有効な状態は、モデルが認識していない可能性のあるより大きなコンテキストに依存する場合があるため、外部検証はおそらくまだ存在することを覚えておいてください。 。

最後に、単体テストの柔軟性は、アプリケーションと基盤となるテクノロジー（言語の選択など）に大きく依存します。どちらのアプローチも単体テストに十分な影響を与えるケースはあまり見たことがありません。

于 2012-01-06T08:17:30.913 に答える
2

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

たとえば aRepositoryまたは aについて考えてみましょうFactory。a のインターフェース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、これは簡単に確認できますが、たとえば、マージする必要がある重複アイテムがあるかどうかをチェックする責任があるOrderクラスでOrderLinesは(送料を節約できます!)OrderOrderLine

于 2012-01-06T08:15:11.387 に答える
0

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

検証に関しては、いつ、何を検証するかに応じて、さまざまな場所に配置できます。

  • ファクトリは、エンティティの作成時に不変条件を適用します

  • 集約ルートは、集約全体に関係する不変条件を強制します

  • 基本的な検証は、多くの場合、エンティティ自体の内部でも実行されます

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

于 2012-02-13T15:44:55.503 に答える