Domain-Driven Design Starter Modelling Process

Domain-Driven Design (DDD) is a concept framework rather than a design method. DDD, as in the books of Evans and Vernon, is a consistent set of concepts and terms, but it does not prescribe a specific process for arriving at a DDD-conformous design. This is where the DDD Starter Modelling Process comes in. It is a pragmatic, practicioners’ guide to approaching large software design tasks. It is not a rigid process, but rather a set of tools and methods that can be used in a flexible way, depending on the situation.

Using DDD Starter as Process Model in the DDD Master Course

Using DDD Starter as Process Model in the DDD Master Course

Our process in the Digital Sciences Master course Domain-Driven Design of Large Software Systems will be roughly aligned to the Domain-Driven Design Starter Modelling Process which is a pragmatic, practicioners’ guide to approaching large software design tasks.

Here is how we will cover the phases listed in the above model in the DDD Master course.

Align

In reality, as in this course, this phase usually happens before you start the project. It is about identifying the stakeholders, aligning with them on the goals of the project, and getting their buy-in. In addition, it is about identifying high-level use cases and the main actors involved.

Discover

This phase is for learning about the domain, and trying to pinpoint the essence of it in a semi-formalized way.

Method used: Event Storming

Here we will use Event Storming as described in Alberto Brandolini’s popular book.

Decompose / Strategize / Organize

In the DDD module, we try to cover these phases jointly, by post-processing the event storming results, defining subdomains, and assigning subteams to them. This work will not be finalized on that day, but will carry over to the subsequent parts of the case study.

Method used: Domain Message Flow Modelling

The method is best described here: https://github.com/ddd-crew/domain-message-flow-modelling. It is a kind of flow diagram, depicting data / control flow to and from your (sub-)domain.

Connect / Define

The subteams will take responsibility for defining their subdomains by bounded context definitions and domain models. As a whole team, we will work on a context map for the whole project.

Method used: Bounded Context Canvas

The bounded context canvas (https://github.com/ddd-crew/bounded-context-canvas) helps to sum up the constituents of a bounded context in somewhat standardized, compact form.

Method used: Aggregate Canvas

The aggregate canvas (https://github.com/ddd-crew/aggregate-design-canvas) uses the aforementioned compact canvas style to sum up what belongs to an aggregate (as a “cluster” of correlated objects - at this stage still quite technology-agnostic). Another useful source is https://domaincentric.net/blog/modelling-aggregates-with-aggregate-design-canvas. The Vaughn Vernon blogs and his “red book” should also be mentionned, as aggregates are an important focus for him.

Some of fields of that canvas can lead to questions, like:

What is the exact meaning of the “Corrective Policies” in field 5? The naive bank account example in the above description is not particularly helpful for this aspect. However, this source gives a quite plausible and sensible explanation: a corrective policy can be used to enforce violations of aggregate invariants, in case such violations are inevitable due to external events.
Where should consumed events be listed? The is a field for “created events” (no. 7), but none for consumed events - although they have a big impact on how this aggregate communicates with the rest of the world. No reference found, we list it with the commands. Use colors as in event storming.
How should the metrics in fields 8 and 9 be interpreted? The above mentioned Kacper Guniak blog post gives good examples here. The actual, realistic numbers should be queried from the business side.

Method used: Context Map

DDD’s strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It’s usually worthwhile to depict these using a context map (Martin Fowler in his very instructive post on bounded contexts). Or, as Vaugn Vernon writes in the “red book” (p. 87): “The Context Map […] is […] a simple diagram that shows the mappings between two or more existing Bounded Contexts.”

A great explanation of what context maps are can be found on Michael Plöd’s site, especially in this speakerdeck (which I present in the workshop). In addition, there is an extensive slide deck of my own, however still in German, as I haven’t translated it yet.

The DDD crew provides detailed material about context mapping. We will use their notation. However, for clarity we will combine this notation with Martin Fowler’s idea to draw the relationship pattern between aggregates, not whole bounded contexts. So it will be a combination of these two:

DDD Crew's way of drawing a context map

Martin Fowler's way of drawing a context map