ドメイン駆動設計では、機能領域 (境界付けられたコンテキスト) 間の懸念を分離し、コンテキスト間の依存関係を最小限に抑えようとします。同じエンティティでも、異なるコンテキストでは異なる内部表現を持つことができます。しかし、コンテキスト間の通信 (公開された API やイベントなど) では、エンティティの表現を各データ コンシューマに合わせて調整するのでしょうか、それとも共通の表現を使用するのでしょうか?
たとえば、営業とサポートのコンテキスト間のよく知られた分離 (Martin Fowler によって図解されている) を取り上げます。両方のコンテキストで、顧客と製品を認識する必要があります。しかし、サポートのコンテキストでは、顧客はチケットのリストを持っています。一方、販売のコンテキストでは、顧客はテリトリーに割り当てられます。おそらく、内部表現は 2 つのコンテキストで完全に異なるでしょう。しかし、公開された API とイベントの場合、これらの両方の機能を含む単一の Customer モデルがありますか、それともコンテキストごとに複数のモデルがありますか?
個別の境界付けられたコンテキストを持つことのポイントは、システムの残りの部分を気にすることなく、その特定のコンテキストに適した方法でエンティティを自由に表現できるようにすることです。これは、限定されたコンテキスト内で機能の明確さとデータの機密性を主に管理する方法です。したがって、 Customer をコンテキストごとに異なる方法で表現することは間違いなく理にかなっています。
個別の境界付けられたコンテキストは、異なるMicroservicesと考えることができます。これらは個別にデプロイおよびスケーリングされ、データを共有しません。それらの API は独立しており、独自のコンテキストの機能に対応しています。モデルを所有し、アプリケーションの残りの部分を心配することなく、境界内でデータの機密性を維持する責任があります。
関連する概念に異なるモデルがある場合、多くの場合、コンテキスト全体で同じアイデンティティを保持する必要があることに注意してください。これを実現するには、エンティティを初期化した最初のコンテキストからドメイン イベントを発行し、他のコンテキストが適切に設定されるようにします。
Fowler の例では、販売コンテキストは、顧客が初期化される最初のコンテキストである可能性があります。したがって、販売コンテキストがアイデンティティを生成します。次に、サポート コンテキストは、CustomerCreatedドメイン イベントをリッスンすることでレコードを自身に追加します。たとえば、顧客からの将来のサポート コールを予測します。
異なる境界付けられたコンテキストからのデータを照合する必要がある場合は、通常、ドメイン ロジックの外部にある単純なクエリで動作する別のクエリまたはレポート サービスを作成します。データを取得して表示用に整理するビュー/クエリは、通常、ドメイン ロジックの外にとどまります。