DDD-他の境界コンテキストの集合ルートを参照していますか？
私は個人的なプロジェクトを構築しています。DDDの紹介として、少し分析を行っていますが、頭を悩ませることはできません。
私のERDは次のようになります。
それを検討するために、管理者はレストランをセットアップでき、レストランに複数のテーブルを追加でき、それぞれがXサービス（朝食、ランチ、ダイナーなど）を含むことができる就業日（レストランが開いている日など）をセットアップできます。 ）。これは一種の「管理者」パートであり、別のパート「顧客」パートがあります。ここでは、顧客がアカウントを作成して予約を行うことができ、特定のサービスの特定の日付に、アプリが最適なテーブルを決定します顧客と予約が追加されます（これは基本的に、サービス、テーブル、顧客にリンクされています）。
今私の問題は、次のように、異なる境界のコンテキストで分割できることです。
Restaurant BC：レストラン情報とテーブル設定が含まれます。
予約BC：レストランの営業日、サービス、予約部分が含まれます。
顧客BC：アプリの顧客部分が含まれます。
DDDがドメインには外部への参照がないと言っているので、予約が別のBCで定義されているテーブルと顧客にどのようにアクセスするかがはっきりしないので、テーブル、サービス、顧客のクラスを単に追加することはできません。私の予約クラス。次に、私は何をすべきですか、それらのクラスのIDだけを予約に持っていますか？
予約は顧客にバインドされたコンテキストにバインドされる必要があるため、分割が正しくない可能性がありますか？ BCの設定としてもっといいアイデアがある場合は、遠慮なく撮影してください。
よろしくお願いします！
編集1：
多分私は予約を集約ルートとしてではなく、サービスID、顧客ID、およびテーブルIDを含むValueオブジェクトとして扱うべきですか？問題は、予約が更新される可能性があるため、VOが不変であることに矛盾します。
境界付きコンテキストは、大きなドメインを独立したサブドメインとしてモデル化する方法です。境界のある各コンテキストには、そのコンテキストに固有のいくつかの概念、およびCustomerなどの共有概念の独自の内部モデルがあります。あなたの例は、複数の境界コンテキストを保証するほど複雑ではないようです。すべてのユースケースは予約を中心に展開しており、それは1つのコンテキストにすぎません。
そうは言っても、同じ境界のあるコンテキスト内でも、IDで他のエンティティを参照することをお勧めします（Vaughn Vernonは彼の本および オンライン記事で でこれについて詳しく説明しています）。これは、Reservationを値オブジェクトにしません。それでも、一意のIDとライフサイクルを持つ集約ルートです。
共有カーネルを設計できます。ここで、すべてのジェネリック型とジェネリック操作で、境界コンテキストにまたがるものを定義します。