ついにドメインモデルを構築しています。ドメインモデルには、ドメインオブジェクトを永続性に緩く結合するためのインターフェイスが含まれています。ただし、ドメインモデルオブジェクトを相互にどのように結合する必要があるのか疑問に思っています。
注文は顧客を指しますか、それともICustomerを指しますか？
この投稿では、オブジェクトを積極的にデカップリングする際の問題について言及しており、「[インターフェイス]を使いすぎてしまう」ことを思いとどまらせているようです。ただし、ドメインエンティティが依存している他のエンティティをモックできない限り、ドメインエンティティを実際に単体テストする方法がわかりません。これには、緩い結合が必要です。
また、ピースを交換できるドメインモデルがどれほど現実的かについてもわかりません。
コラボレーターが次の場合、単体テストで具体的なコラボレーターを使用してもかまいません。
1）その動作を明確に指定する包括的な単体テストのセットがあります。
2）手配は難しくありません。
3）外部リソースを利用しません（またはこれらの関連ガイドラインのいずれかを破ります）。
これは、フレームワーククラス（たとえば、DateTimeまたはstring）を使用して常に行います。アグリゲートの子が異常に複雑でない限り、それも信頼できるはずです。
ドメインモデルには、ドメインオブジェクトを永続性に緩く結合するためのインターフェイスが含まれています。
永続性はオブジェクトを永続化します。それらを永続化するためにオブジェクトを認識します。永続性をモデルから切り離しても、何も得られません。ドメインでの変更は、永続層に反映される必要があります。
DDDを実行するときは、ドメインエキスパートと協力してユビキタス言語を特定し、それをコードで表現します。ドメインの専門家がインターフェースについて言及しているのを見たことがありません。ドメイン内の適切な概念を特定することにより、モデル内のARを分離します。一部のドメインサービスにインターフェイスが定義されている場合がありますが、それらがドメイン内の実際のサービスプロバイダーであり、見逃した概念ではないことを確認してください。
また、ピースを交換できるドメインモデルがどれほど現実的かについてもわかりません。
あなたは正しいです、それは現実的ではありません。特定のサービスプロバイダーの実装を交換するかもしれませんが、AR内のエンティティはありますか？私はそうは思わない。
DDDを実行するときは、「エンティティを真に分離する」必要はありません。ドメインモデルを、分離する必要のあるアグリゲートに分割することから始める必要があります。アグリゲートは単体テストの「ユニット」として扱われる必要があるため、アグリゲートの内部では何もモックする必要はありません。
また、可能な限り多くの動作を値オブジェクトに移動すると、値オブジェクト（定義上、不変）のテストが非常に簡単になるため、ドメインモデルをテスト可能にするのに役立ちます。