Designing loosely-coupled systems requires more than carefully designed boundaries. Carefully defined interactions between bounded contexts is equally important.
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.
There are 2 basic formats, but there is no formal specification so adjust the tool to suit your needs if the basic formats don't work for you.
The separate message & contents format uses 2 shapes for each message: 1 for the name and order of the message and a separate box to display the contents of the message (the information it carries).
The benefit of this format is that you can focus on the flow of messages without getting bogged down by the message contents at the start.
Start by showing just the messages flowing between senders and receivers (with the order number on the message).
Then show the contents of each message in a separate box next to each message:
The combined message & contents format uses a single shape to capture the message name, order, and contents.
This format is good when you want to focus on the contents of each message from the beginning.
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
Note: In case of a query, the response is just as important as the request. The information can be seen and represented as one unit, like this
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.
Sometimes messages are time-driven. E.g. scenario: cancel an online order after 5 minutes of inactivity. A visualisation like this could work fine. Important is to pay attention to the semantics: within or after or every 5 minutes are very different conditions.
- DDD Pattern: Library Contexts
- Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts
- Gateway Interchange Contexts
Thanks to all existing and future contributors and 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.
