be careful with the use of the term “Bounded Context”. A “context” defines an area where words have a specific meaning, which may differ from the meaning of the same word in another context. You would want to design systems or components to work within a single context, to avoid pollution of your model.
From your description, I take it that you are designing 2 different components, which store information that may have some relationship. Essentially, the last section (strategic design) of the DDD book by Evans covers this. It a big section, so that’s a clear sign that there’s no easy answer to your question.
But to not completely leave you in the dark (with a blue book), here’s some ideas to hopefully get you going.
If component B needs information that component A “owns”, there are a few approaches:
- Have component A emit events, which component B handles to update its own model
- Have component B perform a query to component A, each time it needs information
- Have component B maintain a copy or derived model, which it queries from A, triggered by an Event emitted by A.
Which choice is best depends on the relationship between A and B (same bounded context? same (sub)domain? same dev team?), their respective non-functional requirements (# updates, lifecycle, SLA) and probably many other factors as well. Note that you’re creating a form of (inevitable) coupling here, so it’s important to design how you want that coupling to be.