DDD - Referencing Aggregate Root of other bounded context?

Question

I'm building a personal project, as an introduction to DDD, I'm doing a little bit of analysis and can't get my head around it.

My ERD looks as follows:

To go over it, as an admin you can setup a restaurant, you can add multiple tables to the restaurant, and you can setup workdays ( like the days the restaurant is opened ) which each can contain X services ( breakfast, lunch, diner e.g.). This is kind of the "admin" part, there is another part, the "customer" part, where a customer can create an account and do a reservation, at a given date for a given service, the app will determine the best table for the customer and a reservation is added ( which is basically a service, table and customer linked ).

Now my problem is that I can split it up in different bounded context, like this:

Restaurant BC: Will contain the restaurant information and the table setup.

Reservation BC: Will contain the workdays, service & reservation part of the restaurant.

Customer BC: Will contain the customer part of the app.

What's not clear to me is how the reservation will access the table & customer which are defined in another BC, as DDD says that a Domain doesn't have references to the exterior, so I cant just add the Table, Service & Customer classes into my Reservation class. What should I do then, only have the ID of those classes in Reservation ?

Maybe my split isn't correct as a Reservation should be bound tot the customer bounded context ? If you guys have a better idea as a setup for BC, feel free to shoot.

Thanks !

EDIT 1:

Maybe I shouldn't treat reservation as an Aggregate Root, but as a Value object containing a Service ID, Customer ID & Table ID ? The problem is a reservation could an will be updates, so that's contradictory to the VO being immutable.

Answer 1

Bounded contexts are a way of modeling a large domain as independent sub-domains. Each bounded context will have several concepts unique to that context, and also its own internal model for shared concepts such as Customer. Your example doesn't seem complex enough to warrant multiple bounded contexts. All of your use cases revolve around reservations, and that is just one context.

With that being said, it is a good idea to reference other entities by ID even within the same bounded context (Vaughn Vernon discusses this in detail in his book and in online articles). This doesn't make Reservation a value object, it is still an aggregate root with a unique identity and lifecycle.

Answer 2

You can design a shared kernel, where you will have all your generic types and generic operations define which spans your bounded contexts.