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 organizational 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 choosing boundaries using Design Heuristics, and validating them with Message Flows. Next, we will be evaluating contexts with Core Domain Charts, designing teams using Team Topologies, formalizing contexts with Bounded Context Canvas, and ending on aggregate modeling with Aggregate Design Canvas.

Who is this for?

Senior Software Developers, Architects, Principles, and Technical Product Managers responsible for leading the discovery and delivery efforts of complex software systems.

No prior DDD experience is required, but this workshop is targeted at senior people and assumes experience with building systems with multiple teams collaborating with each other.

What you will learn

• Explore and understand a business domain using Event Storming

• Choose service boundaries using modeling heuristics

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

• Classify contexts and prioritize areas for strategic investment

• Organize teams aligned with the business, domain, and cognitive load

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

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

Agenda

Session 1

• DDD Modelling Process overview

• Introduction to the training domain

• Big-Picture Event Storming

Session 2

• Bounded Contexts

• Decomposing large systems with Design Heuristics

• Validating boundaries with Message Flows

Session 3

• Bounded Context classifications

• Introduction to Team Topologies

• Aligning teams and Bounded Contexts

Session 4

• Bounded Context Canvas

• Design-level Event Storming

• Aggregate Design Canvas

Prerequisites

Minimum 5 years of professional background, experience working on software projects involving multiple teams and systems.