How Should Bounded Contexts Interact with a Central Tenant Context in DDD?

Question

I have a question regarding bounded contexts in DDD terms.

Let's assume that I have bounded context called Tenant (With Tenant Admin who can create Tenant Member), Library (With Reader, who can just read books), Parking (With a Valet service) and Billing (Which could be OHS)

Now, I'm wondering how all those BCs should be related to Tenant context.

Tenant context is surely some kind of Tenant Management where you can create Tenant Member. Tenant Member should be able to become Reader and maybe a potential Valet. Tenant Admin however, should become some kind of admin in those BCs, especially in Billing BC

It's kinda confusing for me that the more BCs I will have, the more will be connected to Tenant. They will have to listen for events from Tenant BC and probably act as conformist.

Giving an example story:

I create a new Tenant called Microsoft. Tenant Microsoft can create Tenant Employees.

Now, I want to make one of my Tenant Employee ([email protected]) a Valet on the parking, and the another one ([email protected]), Reader in Library.

And this is the point that confuses me. Who and when should "create" Valet or Reader?

Should those BCs listen for a kind of event from Tenant context and create their corresponding representations for Tenant Employee (Valet, Parking) as "Read models", so when I enter into Library context, I can select John or Mark?

So, basically, should I be worried that so many BCs will depend on that one (Tenant) or it seems normal? Because If I add new contexs like Sales, Warehouse, HR etc. then they all will somehow depends on Tenant context

Answer 1

Bounded contexts should not have hard dependencies on one another. You don't want types from one bounded context being referenced in another bounded context, so no, they should not depend on one another. Business workflows are a different story, though. That is not a technical dependency.

I think the challenge here is understanding the desired workflows from your end users' perspective. Without defining that, you will never know how these bounded contexts interact or who should initiate the workflow.

At first glance, the separation between tenants, valets, billing, and library seems sensible, but this is hard to judge without knowing the requirements you've been asked to implement. The valet, billing, and library bounded contexts will likely save the IDs of tenants or tenant employees to their own data store. This is the preferred way for aggregate roots to cross bounded contexts, but your question is about interaction, not data.

You will need to decide which one of these aggregate roots comes first, and this will be determined by the use cases. The application might have a use case to create a valet as a new employee. The application then needs to coordinate calls to two bounded contexts or services. This logic would sit closer to the user, perhaps in some controller for a web API serving the front end. On the other hand, your application might want to support a use case to make an existing tenant employee a valet. Perhaps they transfer from one position to another. Again, the application should support a use case to coordinate calls to whichever services are necessary for each bounded context.

I think having the bounded contexts listen for events from each other is problematic in this case. There is no clear indication how the Valet bounded context would know that Mark should be a valet, but John should not. You would need to pass some discriminator value in the event when a new Tenant Employee gets registered. The problem here is that the Tenant bounded context suddenly needs to know about Valets, Billing, and the Library. This breaks encapsulation.

I would recommend taking a step back and looking at this problem from the perspective of the end user. What use cases and workflows are you automating with your software? I'm willing to bet the ideal interaction between bounded contexts will exist higher up in the call stack closer to the actual use case being modeled in the application rather than events between bounded contexts.