Designing loosely-coupled systems requires more than carefully designed boundaries. Carefully defined interactions between bounded contexts is equally important for avoiding tight coupling as Stefan Tilkov articulates:
I think that for any given interaction triggered by some outside event – like e.g. a user clicking a button after entering data into a form – I’d end up touching maybe 3-5 of them [microservices].
A bounded context is a sub-system in a software architecture aligned to a part of the domain. It can be implemented as a microservice or a module within a monolith.
A Domain Message Flow Diagram is a simple visualisation showing the flow of messages (commands, events, queries) between actors, bounded contexts, and systems, for a single scenario.
When you have an initial cut of your architecture - you have identified candidate bounded contexts - you can begin design the message flows.
Start by creating a list of of scenarios to model. And then for each scenario create a diagram
When creating a diagram, the typical flow is:
- Start with an actor/context/system
- Create the message they want to send
- Add the recipient of the message and a line connecting the sender and the receiver
- Place the message close to the line
- Repeat steps 1 - 4 until your scenario is complete
The message should contain 3 elements:
- The name of the message
- The significant data contained within the message
- The order in which the message occurs in the flow being modelled
The number one problem with Domain Message Flow Diagrams, and diagrams in general, is too much information. Miller's Law is a good heuristic to use here. Aim to have between 5 and 9 messages on your diagram.
If you find that adding the data to each message is breaking your flow of progress, you can defer the data section of each message it until you have placed all of your messages.
- DDD Pattern: Library Contexts
- Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts
- Gateway Interchange Contexts
Thank you to the following individuals who have all contributed to Domain Message Flow Modelling:
Domain Message Flow Diagrams are heavily inspired by:
The Domain Message Flow Modelling notation is freely available for you to use. In addition, your feedback and ideas are welcome to improve the technique or to create alternative versions.
Feel free to also send us a pull request with your examples.
This work is licensed under a Creative Commons Attribution 4.0 International License.
