Context mapping - relations

2
votes

Is it considered a bad idea that 2 bounded contexts can have upstream communication between them?

Example for, order BC will publish event, and inventory BC will subscribe for that event and in the same time, inventory BC can publish events and order BC will subscribe

2
domain-driven-designmicroservicesbounded-contexts
Why not communicate directly from order BC to inventory BC and limiting the publish/subscribe mechanism for the feedback from inventory to order? This way, inventory isn't dependent on order. – Markus Pscheidt
@MarkusPscheidt if they communicate directly via rest calls, isn't that considered as anti-pattern and synchronous communication? Order should be able to complete it's job no matter if inventory is available or not, or they should be same MS – Robert
These concerns sound to me like rather technical issues. Even publish/subscribe doesn't guarantee that a published message is received. You could use a queue of events that need to be processed by Inventory, kept in the Order database until REST calls to Inventory were successful. Processing on the side of Inventory can be done asynchronously with feedback to Order via publish/subscribe. – Markus Pscheidt

2 Answers

3
votes

Nope this is NOT a bad idea, in fact this is a great idea, let me explain.

First consider your bounded contexts, in reality they should know nothing about each other, even when multiple Contexts are working together to create a complete solution, all a context knows about is itself, its OWN concerns.

Take an OnboardingContext responsible for when a new employee starts at a company, here an Employee entity is added for the first time into the system. Here the employee has a Name, Phonenumber, Start date, Address, Marital Status and more.

Consider the PayrollContext, it too has an Employee entity but here all this entity has is an Id, a Salary, Start Date and End Date - here it doesn't care about the address, or marital status, it doesn't even necessarily care about the Name, becuase in THIS context name is not important, only the Salary, Start Date and End Date.

So if the two contexts, shouldn't know about each other, but maybe care about some information relating to both, how do we get the fact that a new Employee has started and needs to get paid?

Domain Events

Domain events are used with distributed systems. The model of course, will become more complex, but also more scalable. Domain Events are used in an event driven architecture

Heres how it might work

  1. A new employee starts and is added to the system in the OnboardingContext, everything is correct and the model is persisted successfully.
  2. The OnboardingContext raises an event, the event is called NewEmployeeEvent

Thats it for the OnboardingContext as far as it is concerned it is done. It's handled the new employee, saved it, and raised a nifty system wide event to say that something (an event) has occured.

Now to the PayrollContext

  1. The PayrollContext is interested in a couple of things, in particular it want's to know when a new emplyee starts.
  2. It subscribes to the NewEmployeeEvent this event is of a common type, it doesn't know where the event comes from, in fact it could come from anywhere, but it is interested in a little bag of data, or inormation on that event.
  3. When the event is raised this context handles that event, in this case grabbing pertinent info about the Salary and Employee Number, it persists this to it's own data store for use later during payroll.

Boom done.

Your system now listens to and responds to events, these flow throughout your system, in any direction, in all directions.

When something of interest happens and event is raised, anyone (context) interested in that event subscribes, handles and does what it want's with the data relating to that event.

So how do you do this?

There is lots of reading to do, just google DDD and Domain Events.

You will come across a lot of articles from Jimmy Bogard (a better domain events pattern) and Udi Dahan (Domain Events Salvation) on the subject

Take a look at nservicebus (paid for) and masstransit (open source) they are fantastic out of the box eventing, and messaging systems.

Nservice bus has some great videos on the subject at https://docs.particular.net/nservicebus/architecture/principles

2
votes

Yes, this is a bad idea.

Your design would result in a circular dependency between the two BCs. As in many other areas of software development, circular dependencies are almost always a bad idea.

If your use cases force you to do this, then you should reconsider your context map. Ask yourself the following questions:

  • Are the two BCs really separate BCs, or should they rather be one?
  • Or should a part of one of the BCs that lead to the circular dependency in fact be in a third BC?

Finding answers to these questions in the context of your domain will probably lead you to a cleaner design.