Let's assume there are multiple contexts with the same logical entity but with different notions. Creating such an entity should have the side effect that in all other contexts the same logical entity should be created.

I do this simply by sending a domain event which contains all required fields for all contexts. The issue with that is, that the context which initially creates the new entity is tightly coupled to all other context as it has to build the correct domain event with all required fields from other contexts. How would I remove that coupling?


Let's say for a training management software I discovered the contexts Finance and Training. Both contexts share the logical entity Student. While in Finance a Student has an IBAN number, in Training this information is useless.

Now I want to implement the use case "Register student". This registration should be atomic, i.e. the entity should exist in all contexts. Actually I therefore created a further context Registration. I'm now concerned that the context which initially creates the entity needs to know details from every other context about this entity.

This somehow collides with the idea that a context should create a cohesive model. In this case Teaching and Finance are cohesive, but Registration is not. And no matter where I would shift the creation of that entity, I'm always coupled to other contexts.

Let's assume I will change the entity in the Finance context by adding a further field for e.g. credit. I now have to touch Finance and the Registration context.

Do you see a way to avoid that coupling?

  • 4
    A more concrete example would make your question much easier to understand.
    – Doc Brown
    May 22, 2016 at 21:11
  • I updated the question with an example. Does this explain my situation? May 23, 2016 at 18:06
  • I have provided an update based on the example edited into the question.
    – Erik Eidt
    May 23, 2016 at 18:43

1 Answer 1


I think you're talking about multiple bounded contexts that all speak of the same conceptual entity, while each of the bounded context has different responsibilities around that entity, hence the different notions.

For each type of entity, one of the bounded contexts should have the fundamental responsibility of being authoritative; the other contexts can refer to that entity, even as they adorn with additional information of their own concerns.

The authoritative context, for an entity type, is the only one allowed to accept and enter a new entity of that type into the system as a whole; for example, it is the context that manages the id's for those entities, and responsible for allocating new ids for new entities. For example, allocating customer id's or order id's. The other contexts can refer to these entities by id.

The other contexts do not create new entities for which they are not authoritative, instead they refer those who want to create new entities to the authoritative source. The authoritative context then can send event messages indicating creation (update/deletion as needed) of new entities to the other contexts, possibly by prior arrangement (ie. by subscription).

If you don't do this, and allow independent contexts to accept and enter the same entity information, to allocate new id's for the same new entity, then you're in the territory of tying legacy systems together using Master Data Management. In MDM, each siloed system believes that it is authoritative for the same entity types, accepting and entering and assigning its own primary key to the same entity. Master Data Management's concern then is to map primary keys in one siloed system to primary keys managed in another, dealing with data quality (e.g. name variations among a single customer) issues and overlapping updates at the same time. You effectively end up with multiple primary key sets for the same entity (one for each of the legacy siloed systems that thinks it has the authority for the entity type, and usually, one additional one for the MDM system itself.)

There is a tension between the notion of atomically registered student (with all info for all the other contexts collected at registration) and the desire for loose coupling between contexts. I think you pick one or the other.

I'd probably opt for the looser coupling, and gather (and persist) finance information (e.g. credit) separately from registration. I think that separates concerns appropriately, and otherwise there isn't as much merit to separating the contexts.

My next choice is that I'd prefer to merge all the contexts into one over duplicating credit data between them.

  • Thanks for your answer. MDM is not the case. I do have an authoritative context. My issue now is that creating that entity should also create the referring entities in the other contexts, but also with the required additional information for those contexts. I see only doing this by having the authoritative context depending on the others, so that it could then send events with the additional information for the other contexts. My concern here is the coupling to those other contexts. May 23, 2016 at 18:10
  • @MarkusMalkusch You shouldn't have atomicity between BCs. The solution is to have the registration context publish as StudentRegistered event on a message bus. This event will be enriched with the information related to student registration. The Registration BC doesn't have to be aware of the existence of other contexts.
    – plalx
    May 30, 2016 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.