This document provides an overview of CQRS/DDD/ES concepts and best practices. It discusses: 1. The domain model being the "heart" of an application and focusing on a particular problem domain. 2. The key aspects of CQRS including separating commands and queries, using events to synchronize data, and storing data in a way that matches its usage. 3. The benefits of event sourcing including having a complete history of events, aligning with commands, and being able to replay events to reconstruct state.

1. CQRS/DDD/ES
Beer Time – CEST
Coffee Time – PST
Lunch Time – EST
Snooze Time – ASPAC 
Ask questions in the “Chat” area

2. About Me !
Architect by day / CQRS-ES Evangelist by Night.
20 years of experience primarily building Products in the Financial Services space.
Love to explore and write about Event Driven Architectures.
Author of the book “Practical Domain-Driven Design with Enterprise Java” and the only book with “Axon”
in its name.
InfoQ Editor focused on CQRS/ES.
Writing my second book “Pocket Guide to CQRS/ES using Axon” with Allard Buijze – out in August.
Still learning ! So I might be wrong :)

3. Agenda
The First Steps
02
Roadmap
04
The Foundation
01
Digging in Deeper
03
What is DDD/CQRS/ES ? Peeling off the layers.
Choice of Technology and
Process.
Setting yourself up for
success.

4. THE FOUNDATION
01

5. The Domain Model is the “heart” of an
Application.

6. Domain
A Sphere of knowledge, influence or activity.
The subject area to which the user applies a
program is the domain of the software.
Model
A system of abstractions that describes
selected aspects of a domain and can be used
to solve problems related to that domain.

7. Domain (or Sub-Domain) Categories
Core
Domain
Generic
Supporting
The Money Maker
Off the Shelf (e.g. Identity
Management)
Custom Built (e.g. Document
Management)
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-
ddd-clearly-defined-e0b49c7b586c

8. Travel/Health
Insurance.
Customer
Quotes
Service
Customer
Claims
Service
Policy
Changes
Customer
Onboarding
Service
Customer
Complaints
Terminate
Policy
Model for a Particular Problem Only !

9. Building Blocks
Repositories
Entities Value Objects Aggregates
Events
Bounded
Contexts

10. Structure

11. Scope of Model
What are we
optimizing for ?
Non-Functional
Concerns

12. CQRS
Divide and Conquer

13. Command
Query
Responsibility
Separation
Command Model
Focused on executing tasks.
Primarily expressed in operations.
Only contains data necessary for task execution
and decision making.
Query Model
Focused on delivering information.
Data is stored the way it is used.
Denormalized/”table per view”

14. Building Blocks
Client
Command Model Projections
Commands Queries

15. Synchronization Problem
Client
Command Model Projections
Commands Queries

16. Events as the Glue
Client
Command Model Projections
Commands
Events
Queries

17. CQRS, DDD & EDA
Repository
Command
Event
Query
Projections
(Aggregate, Entit
Value Object, etc

18. Immutability

19. Traditional State Storage
What happened What we store
Flight
flightNo: AC-323
planned departure time: 6:00
planned arrival time: 10:00
captain: T. Cruise
status: awaiting departure
1 Flight scheduled: 6:00 - 10:00
2 Captain assigned: T. Cruise

20. Traditional State Storage
What happened What we store
1 Flight scheduled: 6:00 - 10:00
2 Captain assigned: T. Cruise
3 Departure slot missed: 6:00
4 Captain assigned: C. Lindbergh
…
Flight
flightNo: AC-323
planned departure time: 6:00
planned arrival time: 10:00
captain: C. Lindbergh
status: delayed at gate

21. Traditional State Storage
What happened What we store
1 Flight scheduled: 6:00 - 10:00
2 Captain assigned: T. Cruise
3 Departure slot missed: 6:00
4 Captain assigned: C. Lindbergh
5 Flight departed: 7:34
…
Flight
flightNo: AC-323
planned departure time: 6:00
planned arrival time: 10:00
captain: C. Lindbergh
actual departure time : 7:34
status: in-flight

22. Traditional State Storage
What happened What we store
1 Flight scheduled: 6:00 - 10:00
2 Captain assigned: T. Cruise
3 Departure slot missed: 6:00
4 Captain assigned: C. Lindbergh
5 Flight departed: 7:34
6 Arrival time estimated: 11:30
7 Arrival time estimated: 10:40
8 Flight arrived: 10:24
…
Flight
flightNo: AC-323
planned departure time: 6:00
planned arrival time: 10:00
captain: C. Lindbergh
actual departure time : 7:34
actual arrival time: 10:24
status: arrived
The valuable information is here… Not here

23. Event Sourcing
System Of Events
NOT
System Of State

24. Event Sourcing based Storage
What happened What we store
1 Flight scheduled: 6:00 - 10:00
2 Captain assigned: T. Cruise
3 Departure slot missed: 6:00
4 Captain assigned: C. Lindbergh
5 Flight departed: 7:34
6 Arrival time estimated: 11:30
7 Arrival time estimated: 10:40
8 Flight arrived: 10:24
…
1 Flight scheduled: 6:00 - 10:00
2 Captain assigned: T. Cruise
3 Departure slot missed: 6:00
4 Captain assigned: C. Lindbergh
5 Flight departed: 7:34
6 Arrival time estimated: 11:30
7 Arrival time estimated: 10:40
8 Flight arrived: 10:24
…

25. Characteristics
Complete and truthful
representation of history
• Natural alignment as Commands
result in Events
• Storage Method for Command Model
• Only persist changes
Replay all past Events to arrive
at current state (on an
Aggregate)
Guarantee Command Model State Construction

26. The Beauty of Immutability
Predictable model for
New Feature
Development
Data Mining
Transparency
No loss of context
within the entire
system.
Auditing
Accurate and correct
data.
Debugging
History of changes
makes it easier to
debug and safer to
correct data.
Analytics/Value from
Data
Model
Complexity
Eliminate the Mixed
Model problem.
Evolution

27. The
First Steps
02

28. CQRS/ES is easy to understand,
not as easy to implement
“correctly”

29. System of Events
System of State
NOT

30. All systems are eventually consistent.
Eventual Consistency

31. “Commands”/”Queries” and “Events”
are all “Messages”
Messaging

32. A Component should not be aware, nor make
any assumptions, of the physical location of
Components it interacts with.
Location Transparency

33. ES Capability Map

34. Digging in Deeper
03

35. A pattern name with “Event”
does not mean it is only about “Events”.

36. Event Sourcing != Event Streaming

37. We decided to Kubernetes my Custom CQRS/ES
platform based on Event Driven Microservices !

38. The Akka platform

39. The Axon Platform

40. It is also about the process.

41. Modeling Process Toolkit #1 – DDD Crew
https://github.com/ddd-crew/ddd-starter-modelling-process

42. Modeling Process Toolkit #1 – DDD Crew
Big-Picture
Event Storming
Decomposition
via Design
Heuristics
Validation of
Message Flows
Bounded
Context
Classifications
Team Topologies Bounded
Context Canvas
Design-Level
Event Storming
Aggregate
Design Canvas
And a lot more…..

43. Modeling Process Toolkit #2 – Event Modeling (Adam Dymitruk)

44. Collaboration Swim Lanes Events Commands
Read Models Interfaces
And a lot more…..
Modeling Process Toolkit #2 – Event Modeling (Adam Dymitruk)

45. Roadmap
04

46. A TIMELINE ALWAYS
WORKS FINE
Understand the
importance of
Immutabilty i.e. the
value from Immutable
Data.
Step 1
Choose a purpose-
built platform.
Step 2
Align processes
around these
concepts.
Step 3
Do things
progressively !
Step 4

47. Are you ready to take the leap of faith ?
WHOA!

48. THANKS
www.axoniq.io