ドメイン駆動設計とテスト駆動開発の両方を使用するプロジェクトに取り組んでいます。Evans による DDD の本を読んでいるときに、彼がドメイン内の集約ルートのインターフェースを定義していないことに気付きました。
DDD と TDD の両方を行っている場合、各集約ルートのインターフェイスを定義して、集約ルート クラスを簡単にテストおよびモック可能にする必要がありますか? その場合、集約ルート内に含まれる各エンティティのインターフェイスも定義する必要がありますか?
Google と StackOverflow での検索から、私が探しているものに近い答えを見つけましたが、特に DDD と TDD の両方を実行する場合のアドバイスを探しています。私がこれまでに見た答えでは見落とされがちです。
いいえ、集計に対して直接テストします。集約自体に依存関係を注入するべきではなく、特定の動作に依存関係が必要な場合は、通常、それをインターフェイスとして表現する必要があります。集合体のインターフェースは不必要な抽象化です - 動作の実装は 1 つしかありません - それがポイントです。また、BDD と DDDも参照してください。ビヘイビア駆動開発は TDD の進化形と見なすことができ、DDD とうまく連携します。
私は、ドメインを使用するクライアントのテストを容易にするために、すべてのエンティティとドメイン サービスのインターフェイスを定義することに慣れています。さらに、このようなアプローチは、必要に応じて AOP を容易にします。
値オブジェクトに関しては、依存します。たとえば、イベント引数、識別子、例外(明らかに)、およびその他の種類の「契約」にはインターフェイスを使用しません。ただし、クライアント コードのテストの分離を容易にするために、インターフェイスを導入する必要がありました。したがって、私の経験則は次のとおりです。値オブジェクトを目的の状態にするには、クライアントは何ステップ必要ですか? 複数の場合 (または 2 つ、良識は私の友人です :-D)、最初からインターフェイスを導入します。
すべての集計もエンティティであるため、集計について話しているわけではないことに注意してください。