私は現在、DDDの原則に基づいて、製品/パーティ管理システムの概念実証を作成中です。要件の1つは、パーティデータ（顧客、再販業者）がWeb上のCRMに保存され、製品固有のデータがオンプレミスのSQLデータベースに保存されることです（以下を参照）。
CRMシステム（Webベース）
顧客（名前、住所、電子メール、連絡先設定など
が含まれます）リセラー（名前、住所、アクティブステータスが含まれます）
製品システム（オンプレミス）
BaseProduct（バニラ製品を定義）
ResellerProduct（再販業者が販売する基本製品のカスタマイズを定義）CustomerProduct（顧客が登録した製品を定義）。
私は、ソリューションを実装する方法のさまざまなアプローチについて多くの調査を行ってきましたが、すべての概念とそれらが私の問題にどのように適用されるかを理解するのに苦労しています。
私は、エリアを2つの異なる境界のあるコンテキスト、パーティーと製品に分割することから始めました。これらのコンテキストごとにドメインモデルを定義し、エンティティが他のモデルの概念を参照する場合、これらを単純なGuid IDとして残しました（つまり、製品ドメインのCustomerProductは関連するGuidのCustomerRef値を持ちます）。
次に、Web CRMへのAPI呼び出しを使用するPartyインフラストラクチャの実装と、NHibernateを使用するProductインフラストラクチャの実装を実装しました。これらのそれぞれについて、UnitOfWorkを実装して、各コンテキストでトランザクションプロセスを制御できるようにしました。アプリケーション層には、実行時に2つのコンテキストが挿入され、それらが使用されます。
例えば：
- ApplicationService.RegisterNewProduct（customerId、ProductId）
- 各作業単位のトランザクションを開始します（PartyUnitOfWork.Begin（）、ProductUnitOfWork.Begin（））
- 各コンテキストのリポジトリを使用して、関連するドメインオブジェクトを検索します（Party.Customer.Find（Id）、Product.ResellerProduct.Find（Id））
- ロジックを実行して、顧客が適格かどうか、製品が有効かどうかなどを判断します。
- 新しいCustomerProductを作成し、製品システムに保存します
- 各コンテキストをコミットするUnitOfWork
次に、境界のあるコンテキストをもう少し詳しく調べ始め、各コンテキストが他のコンテキストからの概念の限定された表現を持つようにアプリをリファクタリングすることを考えていましたが、そのコンテキストにのみ固有です。つまり、製品のコンテキストでは、ID、名前、アクティブステータスはあるが、連絡先の設定などはない顧客エンティティがあります。次に、DomainEventsを使用して、異なるシステム間のアクティビティを調整し、データを最新の状態に保ちます（つまり、 CRMシステムで新しい顧客が作成され、製品システムによってイベントが発生して処理され、顧客の表現が更新されます）。したがって、上記の例は変更されるため、Productコンテキストのみが使用されました。
さらに混乱させるために、「RegisterNewProduct」呼び出しも新しい顧客を作成したとしましょう。Productシステムで顧客を作成し、Partyシステムによって処理される「NewCustomer」イベントを発生させますか？
これらのアイデアについて人々のコメントを集めたいと思いますか？