DDD Modelling Process: From Problem to Solution Space

Breaking a large domain into subsystems is an exercise that many companies are going through when they kick off a new project or decide to migrate from a monolith architecture to microservices. The approach of creating a number of loosely coupled software services promises to bring a lot of benefits.  These include improving team autonomy, reducing lead time, being able to innovate, and other traits that describe accelerated delivery cycles. 

In theory by making services smaller we should be able to improve the metrics and benefit from a new architecture, but such an approach is missing an important point. If we want to have truly autonomous teams and services that are not tightly coupled with each other, first we need to understand the domain. 

In this training session we will dive into exploring and understanding the domain - our problem space. With this knowledge we will be able to design a loosely coupled microservice system aligned with business needs and organisational structure. In order to achieve these goals, the participants will learn and use a number of tools and techniques. Starting with Big Picture Event Storming, through Design Heuristics, Message Flows, Context Mapping, team design using Team Topologies, Design-Level Event Storming, and ending with a clear definition of a subsystem formalised using a Bounded Context Canvas.

Learning outcomes:

• Explore and understand a business domain using Event Storming

• Choose service boundaries using modelling heuristics

• Validate design and identify coupling in a system using message flows

• Classify contexts and prioritise areas for strategic investment

• Organise teams aligned with business, domain and cognitive load

• Create domain model of a subsystem, define its public interface and policies, commands, events, and reactive processes driving the implementation

• Explain the steps involved in Domain-Driven Design Modelling Process