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.
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.
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.
This phase is for learning about the domain, and trying to pinpoint the essence of it in a semi-formalized way.
Here we will use Event Storming as described in Alberto Brandolini’s popular book.
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.
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.
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.
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.
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:
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:
(c) DDD Crew, https://github.com/ddd-crew/context-mapping)
(c) Martin Fowler, https://martinfowler.com/bliki/BoundedContext.html