On the state of domain-oriented modelling after one and a half decades of DDD
For many years, the three of us have been helping to develop business software – software, that aims to support experts at their workplaces in the best possible way. This is a difficult endeavor; one that cannot be accomplished if we allow specification documents to be “thrown over the wall”, as was once common practice. Agile software development has been a big step in the right direction for us, with principles such as “Business people and developers must work together daily throughout the project.”
Another big step was to make domain modeling an integral part of software development. Approaches like Tool&Material (T&M) and Domain-Driven Design (DDD) put the domain model expressed in code at the core of the software. To achieve this, we need techniques to build an understanding of the application domain among the participants. Software developers must be able to utilize the resulting models for their development tasks. Practitioners have developed suitable approaches and have been using them for years. But it seems that these approaches have only recently been widely recognized and accepted. We summarize the ideas and concepts behind them under the label Collaborative Modeling (hereafter “CoMo”). After “agile” and “domain-driven”, we see “CoMo” as the next big step in the development of business software. This is our first attempt to pinpoint some basic concepts that are shared by various CoMo techniques.
What is Collaborative Modelling?
A few years ago, three of our colleagues were requested to replace a customer’s legacy system. The customer had hired a requirements engineer to help them understand what they expected from the new system. The requirements engineer did a great job, nevertheless, our colleagues had problems finding their way around this new domain. So they asked for a workshop with the requirements engineer and a group of key users. Using some visual storytelling technique, they succeeded in motivating the users to tell stories about their work:
How they achieve their tasks using the legacy system (thus providing a background that explained the needs and priorities of the requirements) and
how they intended to use the new system (providing the context to the requirements).
They even discovered “holes” in their stories that resulted in new requirements. When the development team scaled up, re-telling those stories to the new developers was part of the onboarding process.
CoMo underlies many successful methods that would traditionally be classified as “requirements engineering”. IT experts need to understand the domain, i.e. the tasks and working processes of the users. Software can only reflect what the developers have understood of the domain – otherwise good software cannot be created. Conversely, domain experts and users need to understand what potential software opens up and how digitalization will affect their daily work.
Developers and domain experts need a common language to be able to talk about the domain and the software requirements. CoMo is designed to transport the domain knowledge from the heads of users into the heads of developers, testers, product owners, product managers, business analysts – to everyone involved in software development. The crucial factor here is direct feedback between all those involved. This distinguishes CoMo approaches, for example, from classic requirements techniques in which interviews are conducted and scenarios derived from them.
CoMo is essential in Domain-Driven Design (DDD) – which is probably the most successful method currently available that places domain knowledge at the heart of software development. Domain language, events, actions, resources and structures of the domain form the so-called domain model, which the developers map in the software. A valid domain model can only be created jointly by developers and domain experts. DDD experts such as Paul Rayner now see collaborative modeling as a pillar of DDD:
Distilling the Essence of CoMo
With the success of DDD, the CoMo techniques gained popularity and acceptance. We use several of them frequently and are developing one technique (Domain Storytelling) ourselves. In this article, we will start by looking at four CoMo approaches and distill their essence into a few basic concepts. We will then present our experiences in using the different approaches and outline how we combine them in different situations. Our selection of approaches is not complete. Of course, there are a number of other approaches that are successfully used in practice, such as Event Modeling and Storystorming. In the following we discuss those approaches that we ourselves use in our work and would find it exciting to evaluate other approaches along these lines.
As we assume that many readers are to some degree familiar with these approaches, we will introduce them only briefly:
During EventStorming, developers and experts from various departments use stickers and pens to create a picture of complex business processes. The picture is created “bottom up” from domain events. After a deliberately chaotic start (hence “storming”), a story emerges, captures as a flow of domain events.
Domain Storytelling is a visual storytelling technique, highlighting how people (and software systems) work together. While domain experts tell stories about concrete examples for a business process, a moderator captures the story with a pictographic language. The picture serves as an anchor for discussions between domain experts and developers.
User Story Mapping structures requirements (roughly described as user stories) into a coherent story from the users’ perspective. On sticky notes or cards, the participants describe briefly how they would interact with the software. The horizontal dimension of a user story map depicts a business process or a user journey. The vertical dimension can be used for detailing requirements and prioritization.
In Example Mapping, user stories are the starting point for understanding the problem domain in more detail. Using examples, representatives of the business department, developers and testers in particular should identify the business rules or boundary conditions of a user story in order to derive acceptance tests. User Stories, rules with examples and open questions are each noted on cards of different colors:
Common Concepts of CoMo
We see the following common concepts behind the various CoMo techniques:
Teamwork of the groups involved: People from the business (domain experts, users, product owners, …) and from IT (software developers, architects, UX experts, …) model together. They use modeling to transfer domain knowledge and to clarify scope, workflows, or requirements. A CoMo workshop may require a large group of participants or just a few representatives of some roles. Cross-role collaboration is in stark contrast to individual specialists who conduct interviews, analyze documents, and produce mostly textual output that is consumed by others.
Telling stories: In CoMo workshops, the participants tell stories about scenarios that have happened in the past or that what they want to happen in the future. A scenario is about an instance of a business process (not an abstract description of all possible instances). Each scenario describes a timeline of events, activities, or examples that are relevant to the domain. Once the scenarios are understood, the discussion can move on to the abstractions, rules and case distinctions that are necessary for software development.
Aiming for mutual understanding between all participants through a common language: People often complain that business departments and IT live in their own worlds and are talking past each other. All CoMo approaches, however, focus on the language of the users; the various workshop techniques are supposed to help the participants understand each other better.
Create common models of the application domain: The models produced during storytelling are more than a by-product. Even though they are informal and usually made from drawings, index cards, or post-its, they mark a tangible and usually graphical result that can often be used in further work. Another, maybe even more important purpose of modeling is to drive the storytelling forward. Models visualize the state of the discussion for all participants. Notations for collaborative modeling must be understandable to everyone, i.e. not requiring specialist knowledge to comprehend the notation.
Key Aspects of the Different CoMo Approaches
In the previous section we have identified the common concepts of the different approaches. In practical use, these (and other) approaches have their own focus or features that make them suitable for selection in a concrete project situation. From our experience we give examples of the distinctions of the approaches as we see them. We consider the following aspects:
Goal, i.e. what is the approach good for?
Which scope is being considered?
Which elements are used in the modelling?
Which outcomes (models, objects, artifacts) are produced?
Which activities in the development process are supported by the approach?
What connections to other development methods and modeling approaches exist?
The following compact overview is inevitably subjective, simplistic and not entirely clear-cut. In addition, the approaches cover a wide range of purposes and can be flexibly adapted to one’s own circumstances with a little experience. With this we like to start the discussion in which the authors and users of these approaches should contribute their views and experiences.
User Story Mapping
Why do we model?
Gain a common overview
Identify goals, conflicts and open questions
Recognize business boundaries in processes Software Design
Understanding & designing business processes
Derive requirements for software
Recognize business boundaries in processes
Understanding & detailing software requirements
Define appropriate increments
Decompose software requirements
Making requirements implementable through acceptance criteria
What are we looking at?
Business processes in as-is or to-be
Temporal sequence of events in general
Business processes in as-is or to-be
Cooperation between actors
Interacting with software systems
Key elements of the modelling
if appropriate: policies, systems, actors, software components, …
Human and technical actors
Examples of rules
Image of a business process as a result of events
Image of a domain model
Domain Story as image
Glossary of a Ubiquitous Language
User Story Map with User Journeys and Increments
Example map of a requirement with rules, examples and open questions
User Stories with acceptance criteria
Which development activities are supported?
Software-Design according to DDD
Transition from understanding the problem to implementation
Identification of domain-oriented interfaces to external systems
Prioritizing the IT support of tasks and processes
Design of Mock Ups
Software development with interaction models
Further development and maintenance
software development, esp. implementation
Specification of constraints & rules
Specification of acceptance tests
Connections to other methods
Domain Stories for detailed analysis of cooperation in processes
Context mapping for bounded contexts found
Elaborate business rules in Example Mapping
Event Storming for Software Design according to DDD
Context mapping for bounded contexts found
Use Case Diagrams as overview
Design studio and mock-ups for the interaction model
Example Mapping for derived User Stories
Design studio and mock-ups for the interaction model
Planning according to XP or Scrum
Control handling through Kanban Boards
Working with Backlog
We have also already said that the individual CoMo approaches are often used in combination with each other and as part of an overall approach (such as DDD). Based on our experience, we have presented these connections to other approaches and methods graphically as our guide to the CoMo landscape:
Finally, we will share some personal experiences, which we use to decide which approach to apply.
Event Storming shows its strengths when…
the domain is not very structured, or
if the domain is characterized by time-related processes and status changes, or
it is clear right from the start that there are few common views and goals but a great deal of potential for conflict.
The results of the process modeling can be elaborated into a software design by additional notation elements in smaller workshops. Such a modeling fits well if software is to be built according to DDD.
We prefer to use Domain Storytelling when…
we want to examine cooperative processes by understanding how human (and technical) actors work together, or
we design software-supported to-be processes and then discuss the way from the as-is to the to-be, or
we want to derive functional requirements for process support, or
processes have to be documented.
User Story Mapping
We use User Story Mapping when the to-be processes have already reached a certain maturity and the resulting requirements are being transferred to a backlog. The User Story Map becomes a planning instrument for “cross-functional” agile teams to…
talk to a product owner about priorities and increments and
not to lose sight of the context of a user story and
to clarify which requirements need to be worked out in detail next.
With Example Mapping, we continue to work on the intermediate results of the other approaches when…
we need to analyze the business rules that determine process variants and that we have identified with EventStorming or Domain Storytelling, or
to detail requirements to an implementable level, or
if it becomes clear during planning that requirements must be cut into smaller pieces.
Towards a common understanding of CoMo
With this post we want to initiate a discussion about the essence of the different approaches of CoMo. In our opinion this goes beyond the DDD tool set in a strict sense and into the general agile community and the TDD/BDD methods. For this discussion we have summarized our own experiences and views.
Furthermore, we would like to indicate in which contexts and for which questions each approach is particularly well suited. We also think it is very useful to collect suggestions, how we can combine the approaches in practical projects in order to get continuous support without conceptual breaks. This is also one of the goals behind Visual Collaboration Tools, a book written for and by a community of practitioners.
Finally, we hope that the various advocates of the different CoMo approaches will agree on a common conceptual basis so that the many good ideas can complement each other even more and thus be used more widely.
Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Außerdem geben wir Informationen zu Ihrer Verwendung unserer Website an unsere Partner für soziale Medien, Werbung und Analysen weiter. Unsere Partner führen diese Informationen möglicherweise mit weiteren Daten zusammen, die Sie ihnen bereitgestellt haben oder die sie im Rahmen Ihrer Nutzung der Dienste gesammelt haben.
Cookies sind für die korrekte Funktionsweise einer Website wichtig. Um Ihnen eine angenehmere Erfahrung zu bieten, nutzen wir Cookies zum Speichern Ihrer Anmeldedaten, um für sichere Anmeldung zu sorgen, um statistische Daten zur Optimierung der Website-Funktionen zu erheben und um Ihnen Inhalt bereitzustellen, der auf Ihre Interessen zugeschnitten ist. Sie haben jederzeit die Möglichkeit, dem Einsatz der Cookies zu widersprechen. Wir weisen darauf hin, dass bei der Deaktivierung von Cookies die Funktionalität dieser Website eingeschränkt sein kann. Eine detaillierte Beschreibung der von uns verwendeten Cookies erhalten Sie in unserer Datenschutzerklärung.