When working with Domain-Driven Design (DDD), a bounded context is a core concept. Domain storytelling is a way of finding how people and systems work together within a domain, which then can be used to identify the bounded contexts and how they are interconnected, Stefan Hofer and Henning Schwentner explained at the recent DDD Europe 2018 conference in Amsterdam. Both are working at Workplace Solutions and have been using storytelling when talking with domain experts for a couple of years and thinks it's a useful and additional tool for the modelling tool box.
In domain storytelling you let the domain experts describe how they work. They tell a story which is recorded using a pictographic language, a set of different or symbols and textual annotations to visualize the story:
- Actors, for example a person, a customer, or a more technical thing like a car or a ship
- Work objects, for instance a document or a message, or more abstract things such as a route for a transport.
- Arrows for activities.
Typically, the symbols are customized to fit the domain, giving a person a different pictogram than a ship. When needed text is added to describe what a symbol represents. From the symbols and the text, the goal is then to form sentences that as close as possible read like natural language. The sentences are then appended, and the order is shown by using numbers. Normally if-statements and gateways for decisions in a story are avoided — a story should always cover only one concrete example. The visualization means that domain experts often very quickly can see if a story is misunderstood and correct it.
To find candidates of a bounded context, Hofer and Schwentner use indicators in the stories. Examples of indicators are:
- A one-way information flow
- A difference in language, for example using the same name to describe different things
- Different triggers for different parts. For instance, in one part, work is done daily and, in another part, it's done on demand
When finding three indicators, Hofer is fairly confident that he has found a valid boundary between two distinct bounded contexts, but he emphasizes that this is just an indication — it is not proof. Although a one-way information flow in one story indicates a boundary, if you look deeper into the domain you may find other stories that shows it's a more complex information flow, and thus not a boundary.
For Hofer and Schwentner, it's not enough to find the boundaries between contexts. Business processes are often cooperative work that crosses context boundaries, and they emphasize that the goal is not to build walls, but rather to build models that separate contexts while allowing for people to work together. They want separate models so that they can build software that is easier to understand and is less error prone, but also a system that can be used by different people.
In summary, Hofer and Schwentner believes domain storytelling is a valuable tool and they encourage others to try it out and let them know about the result.
Another modelling tool is Event Storming created by Alberto Brandolini, which he taught during a two-day workshop at the conference.
All presentations at the conference were recorded and will be published during the coming months. The planning for DDD Europe 2019 has started but the exact date has not yet been set.