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:

Collaborative Modelling as a pillar of DDD (Source: Paul Rayner, Workshop at Explore DDD 2018, picture by Martin Schimak)

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.
    “Big Picture” EventStorming with Events and Hot Spots
  • 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.
    Figure 3
  • 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.
    Example of User Story Mapping
  • 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:
    Example Mapping

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.

EventStorming Domain Storytelling User Story Mapping Example 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
  • Structuring Backlogs
  • 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
  • Tasks
  • Activities
  • Goals
  • User stories
  • Domain requirements
  • Key elements of the modelling
    • Domain Events
    • if appropriate: policies, systems, actors, software components, …
    • Human and technical actors
    • Work objects
    • Activities
    • Goals
    • Tasks
    • Activitites
    • User Stories
    • User Stories
    • Rules
    • Examples of rules
    • Open Questions
    Key artifacts
    • 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 Stories
    • 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
    • Requirements elicitation
    • Prioritizing the IT support of tasks and processes
    • Design of Mock Ups
    • Software development with interaction models
    • Planning Increments
    • Backlog Prioritizing
    • 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
    • Preparing Sprints
    • Working with Backlog
    • Test-driven development

    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:

    The CoMo landscape with methods, and artifacts

    Finally, we will share some personal experiences, which we use to decide which approach to apply.

    Event Storming

    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.

    Domain Storytelling

    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.

    Example Mapping

    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.

    References