Context

Exe / Jar / Zip

Objects

Classes

OOP

Design Patterns

Modules

Layers

Project

Developer cares about ...

Tactial Design

Service

Exe / Jar / Zip

Objects

Classes

OOP

Design Patterns

Modules

Layers

Project

Strategic Design

Service

Domain

Domain-Driven-Design

Exe / Jar / Zip

Objects

Classes

OOP

Design Patterns

Modules

Layers

Project

Tactical Design

Strategic Design Tools

Tactical Design Tools

Building Blocks in DDD

Basics

What is Event Storming?

• lightweight method to model a domain
  • within an event storming workshop we work in iterations to add layer by layer of elements to sharpen the picture of a domain
• typical elements
  • ​​domain events, commands, aggregates

  • issues/hot spots, chances

  • external systems, read models, policies

  • users/actors, timers, loops

Why do we use Event Storming?

• knowledge distribution
  • bring together people from different silos
  • domain experts/analysts/developers/architects
• enforcing a sharp timeline
  • experts will create locally ordered sequence of events
  • trigger long-awaited conversation
• following steps
  • structure will emerge
  • people and systems will be displayed
  • every layer sparkles a new type of conversation
  • ...

Iterations

Domain Events

product added to cart

• domain event (past tense)

• orange sticky note

• relevant for domain experts

Example (First Iteration)

Command-Event-Pairs

• command (present tense)

• blue sticky note

• triggers a domain event

product add to cart

Aggregates / Entities

• aggregate/entity

• yellow sticky note

• data that is interacted with

product

Borders & Flow

• find borders where a domain model has a different meaning

• domain events flow between different models

Bounded Contexts

• bounded context/sub-domain

• red sticky note

• core name that is relevant/valid

checkout

Outcome / Big Picture

• narrative/stories/user journey

• line(s)

• multiple storytellings

• common language for everyone

Example

Iterate / Color Puzzle Thinking

event

command

external system

policy

user

user

command

• add new colours/sticky notes: e.g. policies

• challenging value (discover new opportunities, inconsistencies)

• reveal pain points

• enable cross-perspective conversation

Example (End of Day 2)

Example (End of Day 2)

Architecture

provider-ui

storefront-ui

merchant-ui

Frontend

api proxy

tenant

auth

Core

business unit

site

shop

Shop Admin

Product

product

. . .

. . .

. . .

. . .

Bounded Contexts > Microservices

Each sub-domain is implemented as vertical:​

• represents a deployable unit (one or more)
• is exclusively responsible for its services
• owns its data
• communicates with other verticals predominantly by using asynchronous messaging
• provides a REST-API to leverage access to its function

Sub-Domains / Verticals

Ubiquitous Language

• use the same vocabulary for the same concepts
• e.g. domain experts, analysts, developers use same language to describe a problem on the whiteboard

Bounded Context

• area of the problem space where the ubiquitous language is valid
• e.g.
  • customer in sales = social interests, likes, needs
  • customer in support = history, tickets
  • customer in accounting = method of payment
  • customer in order = addresses, availability

Most important terms... I/II

Domain Model

• interpretation of reality
• includes the chosen aspects for implementation
• refers to the abstraction of the subdomain

Most important terms... II/II

A domain model is to a bounded context

what classes are to objects

Context Map

• relation between bounded contexts

Kick-Off

Process

Process

Elements

Actors & Policies

Let's start!