Purpose: to show a real-life example of a Domain Driven Design context map to others and to get feedback. The real names have been taken out.
The “value object x” indicates a central concept in this system which occurs in slightly different forms/meanings dependent of context.
The context map only shows some central objects and relationships. It still may be on the edge of showing to much. I also created more detailed translation maps, concentrating on a subset at a time.
There are also several other systems in play here, but the map focuses on the ones for the most important business functions.
This was not made from a big up-front design process. The contexts appeared as we developed on this project and it was not always a very obvious need for a separate context, but we were very conscious about the tiniest of hints that could indicate this.
Sometimes we had to rip out or split concepts that were intertwined, but doing this early made us able to implement more complicated logic just when and where it was needed without affecting and cluttering the other models. For example, the generic subdomain was huge and complicated and would have totally strangled the core domain and we would have been leaking concepts in both directions.
The path to just expanding the existing context with a “tiny new innocent” behavior is very short (we are all eager to deliver fast), but realizing that you should create a whole new context at this time, requires nothing but hard discipline – something you have to buy into when doing DDD.
In return you will be paid back ten-folds.
Bounded contexts and context maps are a key area of DDD. I recommend these resources:
- Domain Driven Design by Eric Evans
- Implementing Domain Driven Design by Vaughn Vernon
- Context mapping by Alberto Brandolini (article on InfoQ)