SlideShare une entreprise Scribd logo
1  sur  104
Télécharger pour lire hors ligne
CQRS recipes or how to cook your 
architecture 
@tjaskula
But before we dive into CQRS recipes… 
…we have to understand basic layered ones
Maslow pyramid in meal recipes 
Not official, just my own trip 
Culinary 
art 
Fine food 
Home cooking 
Fast food and frozen 
food 
Basic ingredients like 
milk, bread, meat
Hey! How this relates to architecture mate?
Maslow architecture pyramid? 
This should somehow map 
? 
? 
? 
? 
? 
Culinary 
art 
Fine food 
Home cooking 
Fast food and frozen 
food 
Basic ingredients like milk, 
bread, meat
But first let’s tell a little story… 
…of one e-commerce application that I’ve learnt so hard
Once upon a time… a marketing team came in 
…to announce to developers what they have sold
“We need an e-commerce portal. Now!” 
“Do it fast” 
“We need every feature Orders, Product catalog, Suppliers”
Development has started…
In progress…
…Then the developer has came after a while…
E-Commerce portal architecture 
UI 
Domain 
DAL 
DB
Another feature was asked by the business…
But developers just…
It will take another year. Because we’ve built a…
“We need to refactor. Business want’s more features…” 
How to refactor a monolith?
To decouple every 
component, you 
have. 
Evolve domain 
independently, it 
should. 
Handle business 
needs easier, you 
will.
Decouple components 
Handle business logic in isolated domain 
Write unit test because every change is a breaking one 
We have to think it over, but for now let’s wrap up what we’ve learnt
Lesson learnt 1 
Simple architecture, does not scale, 
hard to maintain, often monolithic 
Recipe 1: 
Basic layered 
architecture
Basic layered architecture 
Recipe 1 
Time: from 25 min to infinity 
Preparation: 
Just throw basic code skills in. Mix it up with a 
database and UI and everything will be fine…or not… 
Ingredients 
Difficulty: 
Basic coding skills 
Some infrastructure pieces (DB, etc.) 
Client reviews 
• Can be set up very quickly 
• Easy to understand 
• No need for experienced developers. Juniors can make it 
• Leads quickly to unmaintainable monolith code blocks 
• Not easily evolvable for quickly changing business requirements 
• Not scalable 
• Not performent if charge gets bigger 
• Not testable. You’d better have end-to-end integration tests 
UI 
Domain 
DAL 
DB
Where we’ve been? 
Ah yeah…DECOUPLING stuff
Then this came in 
Let’s decouple ourselves from DB
And decouple us from everything else… 
IoC container 
FTW!
And…
And…
Business ask more futures for Orders, Suppliers, stuff…
UI 
OrderViewModel 
Order 
Architecture v2 
OrderController 
OrderMapper IOrderMapper 
SqlOrderRepository IOrderRepository 
DB 
Infrastructure Domain Presentation
What's the problem with n-layered architectures?
What's the problem with n-layered architectures ? 
Reused Abstraction Principle 
VIOLATED
Over time, more features, more pain…
Because of… 
public class OrderController { 
public OrderController (IOrderValidator order validator, 
IOrderMapper orderMapper, 
IOrderRepository orderRepository 
ISupplierRepository supplierRepository 
IAuthorizationFactory authorizationFactory, 
IUnitOfWork unitOfWork, 
IUserFactory userFactory 
ISession session, 
ILogger logger, 
IOrderCache orderCache 
) { 
} 
}
And because developers spent their time on…
It seems that after a while we have still a monolith
But decoupled 
We need more data on UI and different views per user…
But our model doesn’t support it 
Every time we add a new view our model is broken… 
Views are slower. Users complain…
Your reads from 
writes separate. 
Herh herh herh. 
CQRS, you will do !
We have to think about it… 
Time to wrap up…
Lesson learnt 2 
Domain centric, 
refactorable and evolvable 
Simple architecture, does not scale, 
hard to maintain, often monolithic 
Recipe 2: 
n-layered architecture 
with DI 
Recipe 1: 
Basic layered 
architecture
N-layered architecture with DI 
Recipe 2 
Time: reasonable 
Preparation: 
One must know OOP concepts and the best would be 
also to be aware of SOLID principles… 
Ingredients 
Difficulty: 
OOP skills 
With SOLID principles would be event better 
ORMs and IOCs 
Some infrastructure pieces (DB, etc.) 
Client reviews 
• Can be set up rather quickly 
• Easy to understand 
• Can be tested 
• Can lead to unmaintainable monolith code blocks 
• Not easily evolvable for quickly changing business requirements 
• Not scalable 
• Not performent if charge gets bigger 
UI 
OrderViewMod 
el 
Order 
OrderControlle 
r 
OrderMapper IOrderMapper 
SqlOrderReposit 
ory 
IOrderReposito 
ry 
DB
Where we’ve been? 
Ah yeah…CQRS stuff
What is CQRS? 
CQS applied to architecture = CQRS 
Split Read from Writes
Architecture v3 
Command Query 
UI 
Application service Read Model 
Domain 
Repository 
DB Write DB Read
Command 
UI 
Query 
Application service Read Model 
Domain 
Repository 
DB Write 
DB Read denormalized 
Architecture v3 bis
Wow, the speed of views has increased 
We can scale up read and write side independently 
Easy to handle more business request about views and queries 
in denormalized DB
Even of it’s better we still have problems 
Why we have impacts between different business lines? 
Why it takes so much time for a new feature? And we always 
don’t get exactly what we want. There is always a confusion.
Integration inside of the business 
CRUD events ? 
CQRS not a top level architecture
Domain A Domain B Domain C Domain D 
Composite UI 
UI 
Data Access Layer 
Web / 
Application 
Tier 
Background 
server Tier 
Storage Tier 
DDD layered 
application 
Write 
model 
Read 
model 
Legacy application 
CRUD architecture (simple 
non-core domain 
functionality) 
DDD (core domain 
functionality) 
CQRS (core domain 
functionality) 
Legacy subsystem
How to know where to put the effort?
What is the strategic advantage of my company?
Order management system is our strategic goal…
Great then we know where to put our effort…
But how do we find the best model for a business…
To them about 
events talk. 
Find it meaningful, 
will they. Yeesssssss.
The quest has started 
Event Storming = Domain Discovery Tool 
source : Brandolini http://bit.ly/1s1dwoB
Events, that’s the way we think about it!
From events, to aggregates…It’s DDD!
Domain Driven Design 
It’s much more than just commands and events 
• Ubiquitous Language 
• Bounded Context 
• Context Map 
• Domain Event 
• Aggregates
We need a new feature concert ticket sell
Done!
System is unusable users are blocked!!!
Ah no, what to do?
Express business 
intent in commands 
and facts in events, 
you will. 
Make events 
asynchronous, you 
will. Herh herh herh.
We have to think about it… 
Time to wrap up…
Lesson learnt 3 
Decoupled and easy to 
integrate with external 
systems 
Domain centric, refactorable 
and evolvable 
Simple architecture, does not scale, 
hard to maintain, often monolithic 
Recipe 3: 
Hexagonal with basic CQRS 
Recipe 2: 
n-layered architecture 
with DI 
Recipe 1: 
Basic layered 
architecture
Basic CQRS 
Recipe 3 
Time: mid-term 
Preparation: 
Establish a ubiquitous language with your domain 
experts and express it in the code 
Ingredients 
Difficulty: 
OOP skills 
SOLID principles 
Domain Driven Design would be a big advantage 
Client reviews 
• Scale out read from writes independently 
• Can handle more business request about queries 
• More maintainable code 
• Even easier to test 
•Users still can be blocked read and write are synchronous 
• Not so performent for big charges 
UI 
Domain 
Repository 
DB 
Wri 
te 
Read 
Model 
Applicatio 
n service 
DB 
Rea 
d 
denorm 
alized
Where we’ve been? 
Ah yeah commands and events…asynchronous
Command, it’s business intent like “Place Order” 
Event, it’s business immutable fact like “OrderPlaced”
Architecture v4 
Read Model Application service 
Command Bus 
Domain Repository 
DB Write 
DB Read 
UI 
Command Handler 
Event Bus 
Read model 
generator 
Another context application 
Command 
Event 
Dependency
Architecture v4’ 
Read Model Application service 
Domain Repository 
DB Read DB Write 
DB Write 
Application service Read Model 
DB Read 
Command Handler 
Command Bus 
Event Bus 
Read model 
generator 
ACL 
Command Handler 
Domain Repository 
Read model 
generator 
UI 
Command 
Event 
Dependency
Architecture v4’’ 
Read Model Application service 
Domain Repository 
DB Read DB Write 
DB Write 
Application service 
UI 
Command Handler 
Command Bus 
Event Bus 
Read model 
generator 
ACL 
Command Handler 
Domain Repository 
Command 
Event 
Dependency
But there is a trap. Views are not refreshed immediately
CAP Theorem* 
CQRS Ingredients 
Consistency: 
A read sees all previously completed writes 
Availability: 
Reads and writes always succeed 
Partition tolerance: 
Guaranteed properties are maintained even when network failures prevent some 
machines from communicating with others 
* Eric Brewer 
A system can be either CP, AP. CA is not coherent.
CAP Theorem 
CQRS Ingredients 
CP AP 
Node 1 Node 2 Node 1 Node 2 
Data Data Data Data
Eventual Consistency 
CQRS Ingredients 
« A key benefit of embracing eventual consistency is to 
remove the requirement for using distributed transactions » 
Users deal every day with Eventual Consistency
But there is still a trap with event synchronization
Write side Read side 
UI 
Write Model 
DB Write 
Read Model 
DB Read 
Update write side 
data store Update read side 
data store 
Read data 
Transaction Scope
Write side Read side 
UI 
Write Model 
DB Write 
Read Model 
DB Read 
Update write side 
data store 
Send message to 
update read side 
data store 
Read data 
Transaction Scope 
Reliable messaging 
Event Bus
Write side Read side 
UI 
Write Model 
DB Write 
Read Model 
DB Read 
Update 
write side 
data store 
Send message to 
update read side 
data store 
Read data 
Transaction Scope 
Reliable messaging 
Event Bus
I would like to know if user before placing an Order removes 
Items if we propose them more useful articles with our 
recommendation system
That’s a tricky question. We don’t have a history.
All you need, you 
have. 
Use your events, you 
will. Yeesssssss.
We have to think about it… 
Time to wrap up…
Lesson learnt 4 
Easily scalable 
and 
preferment 
Decoupled and easy to 
integrate with external 
systems 
Recipe 4: 
Hexagonal’ish with CQRS + DDD 
Domain centric, refactorable 
and evolvable 
Simple architecture, does not scale, 
hard to maintain, often monolithic 
Recipe 3: 
Hexagonal with basic CQRS 
Recipe 2: 
n-layered architecture 
with DI 
Recipe 1: 
Basic layered 
architecture
Basic CQRS + DDD + Async 
Recipe 4 
Time: long term 
Preparation: 
Gather business intent in form of Commands, map it 
to business events and synchronize everything async. 
Ingredients 
Difficulty: 
Good OOP skills 
SOLID principles 
Domain Driven Design modeling 
Good knowledge of messaging infrastructure 
Application 
service 
Client reviews 
• Handles concurrent domains 
• Scale out read from writes independently 
• Can handle more business request about queries 
• Business process explicit 
• Even easier to test 
• Many moving parts 
• Sometimes integration points between systems are harder to 
grasp 
• Bad things can happen if no integration events command are 
stored 
Domain 
Reposito 
ry 
DB 
Write 
Read Model 
Application 
service 
DB 
Read 
DB 
Write 
UI 
Command 
Handler 
Command Bus 
Event Bus 
Read 
model 
generato 
r 
ACL 
Command 
Handler 
Domain 
Reposito 
ry
Where we’ve been? 
Ah yeah storing events…
For legal thing, we would like an audit log
If we got a time machine…
Yes you have it. Events = facts
Event Sourcing 
CQRS Ingredients 
Event as a storage mechanism 
Order 
Order line 
Item 
Shipping 
information 
Order placed 
Added shipping info 
Removed 2 items 245 
Added 3 items 455 
Added 2 items 245 
Order Created
Event Sourcing 
Rolling snapshot 
Order placed 
Added shipping info 
Removed 2 items 245 
Added 3 items 455 
Snapshot 
Added 2 items 245 
Order Created 
Snapshot 
Put on stack Added 3 items 455 
Removed 2 items 245 
Added shipping info 
Order placed
Read Model Application service 
Command Bus 
Domain 
Event 
Store 
DB Read 
UI 
Command Handler 
Event Bus 
Read model 
generator 
Another context application 
Command 
Event 
Dependency
Read Model Application service 
Domain 
Event 
Store 
Application service Read Model 
DB Read DB Write 
DB Read 
UI 
Command Handler 
Command Bus 
Event Bus 
Read model 
generator 
ACL 
Command Handler 
Domain Repository 
Read model 
generator 
Command 
Event 
Dependency
Read Model Application service 
Command Bus 
Domain 
Event 
Store 
UI 
Command Handler 
Event Bus 
Another context application 
Command 
Event 
Dependency
Our system seems to be on the right track now !
Lesson learn 5 
Resilient 
Recipe 5: 
Hexagonal’ish with CQRS + DDD + ES 
Easily scalable 
and 
preferment 
Decoupled and easy to 
integrate with external 
systems 
Recipe 4: 
Hexagonal’ish with CQRS + DDD 
Domain centric, refactorable 
and evolvable 
Simple architecture, does not scale, 
hard to maintain, often monolithic 
Recipe 3: 
Hexagonal with basic CQRS 
Recipe 2: 
n-layered architecture 
with DI 
Recipe 1: 
Basic layered 
architecture
Basic CQRS + DDD + ES 
Recipe 5 
Time: long term 
Preparation: 
Make your events talk. 
Ingredients 
Difficulty: 
Good OOP skills 
SOLID principles 
Domain Driven Design modeling 
Good knowledge of messaging infrastructure 
Functional thinking 
Client reviews 
• Handles concurrent domains 
• Scale out read from writes independently 
• Can handle more business request about queries 
• Business process explicit 
• Audit log, testing and infinite business views on data 
• Many moving parts 
• Sometimes integration points between systems are harder to 
grasp 
• Bad things can happen if no integration events command are 
stored 
Domain 
Event 
Store 
Read Model 
Application 
service 
DB 
Read 
DB 
Write 
Read Model 
Application 
service 
DB 
Read 
UI 
Command 
Handler 
Command Bus 
Event Bus 
Read 
model 
generator 
ACL 
Command 
Handler 
Domain 
Repositor 
y 
Read 
model 
generator
Maslow architecture pyramid 
Not official, just my own trip 
Resilient 
Easily scalable 
and 
preferment 
Decoupled and easy to 
integrate with external 
systems 
Domain centric, refactorable 
and evolvable 
Simple architecture, does not scale, 
hard to maintain, often monolithic 
Culinary 
art 
Fine food 
Home cooking 
Fast food and frozen 
food 
Basic ingredients like milk, 
bread, meat
What CQRS is not? 
CQRS Basics/From CQS to CQRS
Is CQRS for me? 
CQRS Basics/From CQS to CQRS 
What kind of problem do I try to solve ? 
• Collaborative domain 
• Locking the data without blocking the user 
• Read data scalability 
• Performance optimization 
• Complex workflows / Temporal data / Stale data
There is more 
Aggregates 
• Validation 
• Uniqueness checking 
• Existence checking 
• Replaying of events (Event Sourced) 
Long running workflows 
Optimization
Long running workflows 
CQRS Deep Dive Cooking 
How do I know if I need one? 
Difference between Saga and Process Manager?
Client 
Order 
Aggregate 
Order Process 
Manager 
Stock 
Aggregate 
Payment 
Aggregate 
2. OrderPlaced 
3. Make reservation 
4. ItemsReserved 
5. Make payment 
6. PaymentAccepted 
7. OrderConfirmed 
7. OrderConfirmed 
7. OrderConfirmed
Questions ?

Contenu connexe

Tendances

Big Data Redis Mongodb Dynamodb Sharding
Big Data Redis Mongodb Dynamodb ShardingBig Data Redis Mongodb Dynamodb Sharding
Big Data Redis Mongodb Dynamodb ShardingAraf Karsh Hamid
 
CQRS: Command/Query Responsibility Segregation
CQRS: Command/Query Responsibility SegregationCQRS: Command/Query Responsibility Segregation
CQRS: Command/Query Responsibility SegregationBrian Ritchie
 
The Art of Discovering Bounded Contexts
The Art of Discovering Bounded ContextsThe Art of Discovering Bounded Contexts
The Art of Discovering Bounded ContextsNick Tune
 
Microservices, Containers, Kubernetes, Kafka, Kanban
Microservices, Containers, Kubernetes, Kafka, KanbanMicroservices, Containers, Kubernetes, Kafka, Kanban
Microservices, Containers, Kubernetes, Kafka, KanbanAraf Karsh Hamid
 
Domain Driven Design (DDD)
Domain Driven Design (DDD)Domain Driven Design (DDD)
Domain Driven Design (DDD)Tom Kocjan
 
Microservices Part 3 Service Mesh and Kafka
Microservices Part 3 Service Mesh and KafkaMicroservices Part 3 Service Mesh and Kafka
Microservices Part 3 Service Mesh and KafkaAraf Karsh Hamid
 
Hands-On Introduction to Kubernetes at LISA17
Hands-On Introduction to Kubernetes at LISA17Hands-On Introduction to Kubernetes at LISA17
Hands-On Introduction to Kubernetes at LISA17Ryan Jarvinen
 
Kafka as an event store - is it good enough?
Kafka as an event store - is it good enough?Kafka as an event store - is it good enough?
Kafka as an event store - is it good enough?Guido Schmutz
 
[pgday.Seoul 2022] PostgreSQL with Google Cloud
[pgday.Seoul 2022] PostgreSQL with Google Cloud[pgday.Seoul 2022] PostgreSQL with Google Cloud
[pgday.Seoul 2022] PostgreSQL with Google CloudPgDay.Seoul
 
CQRS and Event Sourcing
CQRS and Event Sourcing CQRS and Event Sourcing
CQRS and Event Sourcing Inho Kang
 
Microservices Architecture - Bangkok 2018
Microservices Architecture - Bangkok 2018Microservices Architecture - Bangkok 2018
Microservices Architecture - Bangkok 2018Araf Karsh Hamid
 
MicroServices with Containers, Kubernetes & ServiceMesh
MicroServices with Containers, Kubernetes & ServiceMeshMicroServices with Containers, Kubernetes & ServiceMesh
MicroServices with Containers, Kubernetes & ServiceMeshAkash Agrawal
 
A Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation SlidesA Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
 
Hexagonal Architecture.pdf
Hexagonal Architecture.pdfHexagonal Architecture.pdf
Hexagonal Architecture.pdfVladimirRadzivil
 
Event-Driven Microservices With NATS Streaming
Event-Driven Microservices With NATS StreamingEvent-Driven Microservices With NATS Streaming
Event-Driven Microservices With NATS StreamingShiju Varghese
 
Domain Driven Design: Zero to Hero
Domain Driven Design: Zero to HeroDomain Driven Design: Zero to Hero
Domain Driven Design: Zero to HeroFabrício Rissetto
 
Real World Event Sourcing and CQRS
Real World Event Sourcing and CQRSReal World Event Sourcing and CQRS
Real World Event Sourcing and CQRSMatthew Hawkins
 

Tendances (20)

Big Data Redis Mongodb Dynamodb Sharding
Big Data Redis Mongodb Dynamodb ShardingBig Data Redis Mongodb Dynamodb Sharding
Big Data Redis Mongodb Dynamodb Sharding
 
CQRS: Command/Query Responsibility Segregation
CQRS: Command/Query Responsibility SegregationCQRS: Command/Query Responsibility Segregation
CQRS: Command/Query Responsibility Segregation
 
The Art of Discovering Bounded Contexts
The Art of Discovering Bounded ContextsThe Art of Discovering Bounded Contexts
The Art of Discovering Bounded Contexts
 
Microservices, Containers, Kubernetes, Kafka, Kanban
Microservices, Containers, Kubernetes, Kafka, KanbanMicroservices, Containers, Kubernetes, Kafka, Kanban
Microservices, Containers, Kubernetes, Kafka, Kanban
 
Domain Driven Design (DDD)
Domain Driven Design (DDD)Domain Driven Design (DDD)
Domain Driven Design (DDD)
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Microservices Part 3 Service Mesh and Kafka
Microservices Part 3 Service Mesh and KafkaMicroservices Part 3 Service Mesh and Kafka
Microservices Part 3 Service Mesh and Kafka
 
Hands-On Introduction to Kubernetes at LISA17
Hands-On Introduction to Kubernetes at LISA17Hands-On Introduction to Kubernetes at LISA17
Hands-On Introduction to Kubernetes at LISA17
 
Kafka as an event store - is it good enough?
Kafka as an event store - is it good enough?Kafka as an event store - is it good enough?
Kafka as an event store - is it good enough?
 
[pgday.Seoul 2022] PostgreSQL with Google Cloud
[pgday.Seoul 2022] PostgreSQL with Google Cloud[pgday.Seoul 2022] PostgreSQL with Google Cloud
[pgday.Seoul 2022] PostgreSQL with Google Cloud
 
CQRS and Event Sourcing
CQRS and Event Sourcing CQRS and Event Sourcing
CQRS and Event Sourcing
 
Microservices Architecture - Bangkok 2018
Microservices Architecture - Bangkok 2018Microservices Architecture - Bangkok 2018
Microservices Architecture - Bangkok 2018
 
Introduction to DDD
Introduction to DDDIntroduction to DDD
Introduction to DDD
 
MicroServices with Containers, Kubernetes & ServiceMesh
MicroServices with Containers, Kubernetes & ServiceMeshMicroServices with Containers, Kubernetes & ServiceMesh
MicroServices with Containers, Kubernetes & ServiceMesh
 
A Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation SlidesA Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation Slides
 
Hexagonal Architecture.pdf
Hexagonal Architecture.pdfHexagonal Architecture.pdf
Hexagonal Architecture.pdf
 
Event-Driven Microservices With NATS Streaming
Event-Driven Microservices With NATS StreamingEvent-Driven Microservices With NATS Streaming
Event-Driven Microservices With NATS Streaming
 
Domain Driven Design: Zero to Hero
Domain Driven Design: Zero to HeroDomain Driven Design: Zero to Hero
Domain Driven Design: Zero to Hero
 
Event Storming and Saga
Event Storming and SagaEvent Storming and Saga
Event Storming and Saga
 
Real World Event Sourcing and CQRS
Real World Event Sourcing and CQRSReal World Event Sourcing and CQRS
Real World Event Sourcing and CQRS
 

Similaire à CQRS recipes or how to cook your architecture

Building data pipelines at Shopee with DEC
Building data pipelines at Shopee with DECBuilding data pipelines at Shopee with DEC
Building data pipelines at Shopee with DECRim Zaidullin
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
 
Better and Faster: A Journey Toward Clean Code and Enjoyment
Better and Faster: A Journey Toward Clean Code and EnjoymentBetter and Faster: A Journey Toward Clean Code and Enjoyment
Better and Faster: A Journey Toward Clean Code and EnjoymentChris Holland
 
Framing the Argument: How to Scale Faster with NoSQL
Framing the Argument: How to Scale Faster with NoSQLFraming the Argument: How to Scale Faster with NoSQL
Framing the Argument: How to Scale Faster with NoSQLInside Analysis
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyComsysto Reply GmbH
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyComsysto Reply GmbH
 
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...Databricks
 
스타트업과 개발자를 위한 AWS 클라우드 태권 세미나
스타트업과 개발자를 위한 AWS 클라우드 태권 세미나스타트업과 개발자를 위한 AWS 클라우드 태권 세미나
스타트업과 개발자를 위한 AWS 클라우드 태권 세미나Amazon Web Services Korea
 
From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...Thibaud Desodt
 
Scaling a High Traffic Web Application: Our Journey from Java to PHP
Scaling a High Traffic Web Application: Our Journey from Java to PHPScaling a High Traffic Web Application: Our Journey from Java to PHP
Scaling a High Traffic Web Application: Our Journey from Java to PHP120bi
 
Scaling High Traffic Web Applications
Scaling High Traffic Web ApplicationsScaling High Traffic Web Applications
Scaling High Traffic Web ApplicationsAchievers Tech
 
The Architect's Two Hats
The Architect's Two HatsThe Architect's Two Hats
The Architect's Two HatsBen Stopford
 
SOA with Zend Framework
SOA with Zend FrameworkSOA with Zend Framework
SOA with Zend FrameworkMike Willbanks
 
Accelerate your Application Delivery with DevOps and Microservices
Accelerate your Application Delivery with DevOps and MicroservicesAccelerate your Application Delivery with DevOps and Microservices
Accelerate your Application Delivery with DevOps and MicroservicesAmazon Web Services
 
Architecting a Large Software Project - Lessons Learned
Architecting a Large Software Project - Lessons LearnedArchitecting a Large Software Project - Lessons Learned
Architecting a Large Software Project - Lessons LearnedJoão Pedro Martins
 

Similaire à CQRS recipes or how to cook your architecture (20)

CQRS recepies
CQRS recepiesCQRS recepies
CQRS recepies
 
Building data pipelines at Shopee with DEC
Building data pipelines at Shopee with DECBuilding data pipelines at Shopee with DEC
Building data pipelines at Shopee with DEC
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuable
 
Better and Faster: A Journey Toward Clean Code and Enjoyment
Better and Faster: A Journey Toward Clean Code and EnjoymentBetter and Faster: A Journey Toward Clean Code and Enjoyment
Better and Faster: A Journey Toward Clean Code and Enjoyment
 
Framing the Argument: How to Scale Faster with NoSQL
Framing the Argument: How to Scale Faster with NoSQLFraming the Argument: How to Scale Faster with NoSQL
Framing the Argument: How to Scale Faster with NoSQL
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and Consistently
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and Consistently
 
Lets focus on business value
Lets focus on business valueLets focus on business value
Lets focus on business value
 
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
 
Lets focus on business value
Lets focus on business valueLets focus on business value
Lets focus on business value
 
Lets focus on business value
Lets focus on business valueLets focus on business value
Lets focus on business value
 
스타트업과 개발자를 위한 AWS 클라우드 태권 세미나
스타트업과 개발자를 위한 AWS 클라우드 태권 세미나스타트업과 개발자를 위한 AWS 클라우드 태권 세미나
스타트업과 개발자를 위한 AWS 클라우드 태권 세미나
 
From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...
 
Scaling a High Traffic Web Application: Our Journey from Java to PHP
Scaling a High Traffic Web Application: Our Journey from Java to PHPScaling a High Traffic Web Application: Our Journey from Java to PHP
Scaling a High Traffic Web Application: Our Journey from Java to PHP
 
Scaling High Traffic Web Applications
Scaling High Traffic Web ApplicationsScaling High Traffic Web Applications
Scaling High Traffic Web Applications
 
The Architect's Two Hats
The Architect's Two HatsThe Architect's Two Hats
The Architect's Two Hats
 
SOA with Zend Framework
SOA with Zend FrameworkSOA with Zend Framework
SOA with Zend Framework
 
Accelerate your Application Delivery with DevOps and Microservices
Accelerate your Application Delivery with DevOps and MicroservicesAccelerate your Application Delivery with DevOps and Microservices
Accelerate your Application Delivery with DevOps and Microservices
 
Symphony Driver Essay
Symphony Driver EssaySymphony Driver Essay
Symphony Driver Essay
 
Architecting a Large Software Project - Lessons Learned
Architecting a Large Software Project - Lessons LearnedArchitecting a Large Software Project - Lessons Learned
Architecting a Large Software Project - Lessons Learned
 

Dernier

React Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App FrameworkReact Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App FrameworkPixlogix Infotech
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesBernd Ruecker
 
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentEmixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentPim van der Noll
 
Dublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptxDublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptxKunal Gupta
 
Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024TopCSSGallery
 
Decarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityDecarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityIES VE
 
Connecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdfConnecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdfNeo4j
 
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)Mark Simos
 
Design pattern talk by Kaya Weers - 2024 (v2)
Design pattern talk by Kaya Weers - 2024 (v2)Design pattern talk by Kaya Weers - 2024 (v2)
Design pattern talk by Kaya Weers - 2024 (v2)Kaya Weers
 
Infrared simulation and processing on Nvidia platforms
Infrared simulation and processing on Nvidia platformsInfrared simulation and processing on Nvidia platforms
Infrared simulation and processing on Nvidia platformsYoss Cohen
 
QMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfQMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfROWELL MARQUINA
 
Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!Memoori
 
Bitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactiveBitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactivestartupro
 
WomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneWomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneUiPathCommunity
 
MuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotes
MuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotesMuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotes
MuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotesManik S Magar
 
Generative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfGenerative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfIngrid Airi González
 
Software Security in the Real World w/Kelsey Hightower
Software Security in the Real World w/Kelsey HightowerSoftware Security in the Real World w/Kelsey Hightower
Software Security in the Real World w/Kelsey HightowerAnchore
 
Landscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfLandscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfAarwolf Industries LLC
 
Potential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsPotential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsRavi Sanghani
 
Deliver Latency Free Customer Experience
Deliver Latency Free Customer ExperienceDeliver Latency Free Customer Experience
Deliver Latency Free Customer ExperienceOpsTree solutions
 

Dernier (20)

React Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App FrameworkReact Native vs Ionic - The Best Mobile App Framework
React Native vs Ionic - The Best Mobile App Framework
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architectures
 
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentEmixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
 
Dublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptxDublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptx
 
Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024Top 10 Hubspot Development Companies in 2024
Top 10 Hubspot Development Companies in 2024
 
Decarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityDecarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a reality
 
Connecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdfConnecting the Dots for Information Discovery.pdf
Connecting the Dots for Information Discovery.pdf
 
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
 
Design pattern talk by Kaya Weers - 2024 (v2)
Design pattern talk by Kaya Weers - 2024 (v2)Design pattern talk by Kaya Weers - 2024 (v2)
Design pattern talk by Kaya Weers - 2024 (v2)
 
Infrared simulation and processing on Nvidia platforms
Infrared simulation and processing on Nvidia platformsInfrared simulation and processing on Nvidia platforms
Infrared simulation and processing on Nvidia platforms
 
QMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfQMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdf
 
Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!
 
Bitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactiveBitdefender-CSG-Report-creat7534-interactive
Bitdefender-CSG-Report-creat7534-interactive
 
WomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneWomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyone
 
MuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotes
MuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotesMuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotes
MuleSoft Online Meetup Group - B2B Crash Course: Release SparkNotes
 
Generative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfGenerative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdf
 
Software Security in the Real World w/Kelsey Hightower
Software Security in the Real World w/Kelsey HightowerSoftware Security in the Real World w/Kelsey Hightower
Software Security in the Real World w/Kelsey Hightower
 
Landscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfLandscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdf
 
Potential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsPotential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and Insights
 
Deliver Latency Free Customer Experience
Deliver Latency Free Customer ExperienceDeliver Latency Free Customer Experience
Deliver Latency Free Customer Experience
 

CQRS recipes or how to cook your architecture

  • 1. CQRS recipes or how to cook your architecture @tjaskula
  • 2. But before we dive into CQRS recipes… …we have to understand basic layered ones
  • 3. Maslow pyramid in meal recipes Not official, just my own trip Culinary art Fine food Home cooking Fast food and frozen food Basic ingredients like milk, bread, meat
  • 4. Hey! How this relates to architecture mate?
  • 5. Maslow architecture pyramid? This should somehow map ? ? ? ? ? Culinary art Fine food Home cooking Fast food and frozen food Basic ingredients like milk, bread, meat
  • 6. But first let’s tell a little story… …of one e-commerce application that I’ve learnt so hard
  • 7. Once upon a time… a marketing team came in …to announce to developers what they have sold
  • 8. “We need an e-commerce portal. Now!” “Do it fast” “We need every feature Orders, Product catalog, Suppliers”
  • 11. …Then the developer has came after a while…
  • 12. E-Commerce portal architecture UI Domain DAL DB
  • 13. Another feature was asked by the business…
  • 15. It will take another year. Because we’ve built a…
  • 16. “We need to refactor. Business want’s more features…” How to refactor a monolith?
  • 17. To decouple every component, you have. Evolve domain independently, it should. Handle business needs easier, you will.
  • 18. Decouple components Handle business logic in isolated domain Write unit test because every change is a breaking one We have to think it over, but for now let’s wrap up what we’ve learnt
  • 19. Lesson learnt 1 Simple architecture, does not scale, hard to maintain, often monolithic Recipe 1: Basic layered architecture
  • 20. Basic layered architecture Recipe 1 Time: from 25 min to infinity Preparation: Just throw basic code skills in. Mix it up with a database and UI and everything will be fine…or not… Ingredients Difficulty: Basic coding skills Some infrastructure pieces (DB, etc.) Client reviews • Can be set up very quickly • Easy to understand • No need for experienced developers. Juniors can make it • Leads quickly to unmaintainable monolith code blocks • Not easily evolvable for quickly changing business requirements • Not scalable • Not performent if charge gets bigger • Not testable. You’d better have end-to-end integration tests UI Domain DAL DB
  • 21. Where we’ve been? Ah yeah…DECOUPLING stuff
  • 22. Then this came in Let’s decouple ourselves from DB
  • 23. And decouple us from everything else… IoC container FTW!
  • 26. Business ask more futures for Orders, Suppliers, stuff…
  • 27. UI OrderViewModel Order Architecture v2 OrderController OrderMapper IOrderMapper SqlOrderRepository IOrderRepository DB Infrastructure Domain Presentation
  • 28. What's the problem with n-layered architectures?
  • 29. What's the problem with n-layered architectures ? Reused Abstraction Principle VIOLATED
  • 30. Over time, more features, more pain…
  • 31. Because of… public class OrderController { public OrderController (IOrderValidator order validator, IOrderMapper orderMapper, IOrderRepository orderRepository ISupplierRepository supplierRepository IAuthorizationFactory authorizationFactory, IUnitOfWork unitOfWork, IUserFactory userFactory ISession session, ILogger logger, IOrderCache orderCache ) { } }
  • 32. And because developers spent their time on…
  • 33. It seems that after a while we have still a monolith
  • 35. We need more data on UI and different views per user…
  • 36. But our model doesn’t support it Every time we add a new view our model is broken… Views are slower. Users complain…
  • 37. Your reads from writes separate. Herh herh herh. CQRS, you will do !
  • 38. We have to think about it… Time to wrap up…
  • 39. Lesson learnt 2 Domain centric, refactorable and evolvable Simple architecture, does not scale, hard to maintain, often monolithic Recipe 2: n-layered architecture with DI Recipe 1: Basic layered architecture
  • 40. N-layered architecture with DI Recipe 2 Time: reasonable Preparation: One must know OOP concepts and the best would be also to be aware of SOLID principles… Ingredients Difficulty: OOP skills With SOLID principles would be event better ORMs and IOCs Some infrastructure pieces (DB, etc.) Client reviews • Can be set up rather quickly • Easy to understand • Can be tested • Can lead to unmaintainable monolith code blocks • Not easily evolvable for quickly changing business requirements • Not scalable • Not performent if charge gets bigger UI OrderViewMod el Order OrderControlle r OrderMapper IOrderMapper SqlOrderReposit ory IOrderReposito ry DB
  • 41. Where we’ve been? Ah yeah…CQRS stuff
  • 42. What is CQRS? CQS applied to architecture = CQRS Split Read from Writes
  • 43. Architecture v3 Command Query UI Application service Read Model Domain Repository DB Write DB Read
  • 44. Command UI Query Application service Read Model Domain Repository DB Write DB Read denormalized Architecture v3 bis
  • 45. Wow, the speed of views has increased We can scale up read and write side independently Easy to handle more business request about views and queries in denormalized DB
  • 46. Even of it’s better we still have problems Why we have impacts between different business lines? Why it takes so much time for a new feature? And we always don’t get exactly what we want. There is always a confusion.
  • 47. Integration inside of the business CRUD events ? CQRS not a top level architecture
  • 48. Domain A Domain B Domain C Domain D Composite UI UI Data Access Layer Web / Application Tier Background server Tier Storage Tier DDD layered application Write model Read model Legacy application CRUD architecture (simple non-core domain functionality) DDD (core domain functionality) CQRS (core domain functionality) Legacy subsystem
  • 49. How to know where to put the effort?
  • 50. What is the strategic advantage of my company?
  • 51. Order management system is our strategic goal…
  • 52. Great then we know where to put our effort…
  • 53. But how do we find the best model for a business…
  • 54. To them about events talk. Find it meaningful, will they. Yeesssssss.
  • 55. The quest has started Event Storming = Domain Discovery Tool source : Brandolini http://bit.ly/1s1dwoB
  • 56. Events, that’s the way we think about it!
  • 57. From events, to aggregates…It’s DDD!
  • 58. Domain Driven Design It’s much more than just commands and events • Ubiquitous Language • Bounded Context • Context Map • Domain Event • Aggregates
  • 59. We need a new feature concert ticket sell
  • 60. Done!
  • 61. System is unusable users are blocked!!!
  • 62. Ah no, what to do?
  • 63. Express business intent in commands and facts in events, you will. Make events asynchronous, you will. Herh herh herh.
  • 64. We have to think about it… Time to wrap up…
  • 65. Lesson learnt 3 Decoupled and easy to integrate with external systems Domain centric, refactorable and evolvable Simple architecture, does not scale, hard to maintain, often monolithic Recipe 3: Hexagonal with basic CQRS Recipe 2: n-layered architecture with DI Recipe 1: Basic layered architecture
  • 66. Basic CQRS Recipe 3 Time: mid-term Preparation: Establish a ubiquitous language with your domain experts and express it in the code Ingredients Difficulty: OOP skills SOLID principles Domain Driven Design would be a big advantage Client reviews • Scale out read from writes independently • Can handle more business request about queries • More maintainable code • Even easier to test •Users still can be blocked read and write are synchronous • Not so performent for big charges UI Domain Repository DB Wri te Read Model Applicatio n service DB Rea d denorm alized
  • 67. Where we’ve been? Ah yeah commands and events…asynchronous
  • 68. Command, it’s business intent like “Place Order” Event, it’s business immutable fact like “OrderPlaced”
  • 69. Architecture v4 Read Model Application service Command Bus Domain Repository DB Write DB Read UI Command Handler Event Bus Read model generator Another context application Command Event Dependency
  • 70. Architecture v4’ Read Model Application service Domain Repository DB Read DB Write DB Write Application service Read Model DB Read Command Handler Command Bus Event Bus Read model generator ACL Command Handler Domain Repository Read model generator UI Command Event Dependency
  • 71. Architecture v4’’ Read Model Application service Domain Repository DB Read DB Write DB Write Application service UI Command Handler Command Bus Event Bus Read model generator ACL Command Handler Domain Repository Command Event Dependency
  • 72. But there is a trap. Views are not refreshed immediately
  • 73. CAP Theorem* CQRS Ingredients Consistency: A read sees all previously completed writes Availability: Reads and writes always succeed Partition tolerance: Guaranteed properties are maintained even when network failures prevent some machines from communicating with others * Eric Brewer A system can be either CP, AP. CA is not coherent.
  • 74. CAP Theorem CQRS Ingredients CP AP Node 1 Node 2 Node 1 Node 2 Data Data Data Data
  • 75. Eventual Consistency CQRS Ingredients « A key benefit of embracing eventual consistency is to remove the requirement for using distributed transactions » Users deal every day with Eventual Consistency
  • 76. But there is still a trap with event synchronization
  • 77. Write side Read side UI Write Model DB Write Read Model DB Read Update write side data store Update read side data store Read data Transaction Scope
  • 78. Write side Read side UI Write Model DB Write Read Model DB Read Update write side data store Send message to update read side data store Read data Transaction Scope Reliable messaging Event Bus
  • 79. Write side Read side UI Write Model DB Write Read Model DB Read Update write side data store Send message to update read side data store Read data Transaction Scope Reliable messaging Event Bus
  • 80. I would like to know if user before placing an Order removes Items if we propose them more useful articles with our recommendation system
  • 81. That’s a tricky question. We don’t have a history.
  • 82. All you need, you have. Use your events, you will. Yeesssssss.
  • 83. We have to think about it… Time to wrap up…
  • 84. Lesson learnt 4 Easily scalable and preferment Decoupled and easy to integrate with external systems Recipe 4: Hexagonal’ish with CQRS + DDD Domain centric, refactorable and evolvable Simple architecture, does not scale, hard to maintain, often monolithic Recipe 3: Hexagonal with basic CQRS Recipe 2: n-layered architecture with DI Recipe 1: Basic layered architecture
  • 85. Basic CQRS + DDD + Async Recipe 4 Time: long term Preparation: Gather business intent in form of Commands, map it to business events and synchronize everything async. Ingredients Difficulty: Good OOP skills SOLID principles Domain Driven Design modeling Good knowledge of messaging infrastructure Application service Client reviews • Handles concurrent domains • Scale out read from writes independently • Can handle more business request about queries • Business process explicit • Even easier to test • Many moving parts • Sometimes integration points between systems are harder to grasp • Bad things can happen if no integration events command are stored Domain Reposito ry DB Write Read Model Application service DB Read DB Write UI Command Handler Command Bus Event Bus Read model generato r ACL Command Handler Domain Reposito ry
  • 86. Where we’ve been? Ah yeah storing events…
  • 87. For legal thing, we would like an audit log
  • 88. If we got a time machine…
  • 89. Yes you have it. Events = facts
  • 90. Event Sourcing CQRS Ingredients Event as a storage mechanism Order Order line Item Shipping information Order placed Added shipping info Removed 2 items 245 Added 3 items 455 Added 2 items 245 Order Created
  • 91. Event Sourcing Rolling snapshot Order placed Added shipping info Removed 2 items 245 Added 3 items 455 Snapshot Added 2 items 245 Order Created Snapshot Put on stack Added 3 items 455 Removed 2 items 245 Added shipping info Order placed
  • 92. Read Model Application service Command Bus Domain Event Store DB Read UI Command Handler Event Bus Read model generator Another context application Command Event Dependency
  • 93. Read Model Application service Domain Event Store Application service Read Model DB Read DB Write DB Read UI Command Handler Command Bus Event Bus Read model generator ACL Command Handler Domain Repository Read model generator Command Event Dependency
  • 94. Read Model Application service Command Bus Domain Event Store UI Command Handler Event Bus Another context application Command Event Dependency
  • 95. Our system seems to be on the right track now !
  • 96. Lesson learn 5 Resilient Recipe 5: Hexagonal’ish with CQRS + DDD + ES Easily scalable and preferment Decoupled and easy to integrate with external systems Recipe 4: Hexagonal’ish with CQRS + DDD Domain centric, refactorable and evolvable Simple architecture, does not scale, hard to maintain, often monolithic Recipe 3: Hexagonal with basic CQRS Recipe 2: n-layered architecture with DI Recipe 1: Basic layered architecture
  • 97. Basic CQRS + DDD + ES Recipe 5 Time: long term Preparation: Make your events talk. Ingredients Difficulty: Good OOP skills SOLID principles Domain Driven Design modeling Good knowledge of messaging infrastructure Functional thinking Client reviews • Handles concurrent domains • Scale out read from writes independently • Can handle more business request about queries • Business process explicit • Audit log, testing and infinite business views on data • Many moving parts • Sometimes integration points between systems are harder to grasp • Bad things can happen if no integration events command are stored Domain Event Store Read Model Application service DB Read DB Write Read Model Application service DB Read UI Command Handler Command Bus Event Bus Read model generator ACL Command Handler Domain Repositor y Read model generator
  • 98. Maslow architecture pyramid Not official, just my own trip Resilient Easily scalable and preferment Decoupled and easy to integrate with external systems Domain centric, refactorable and evolvable Simple architecture, does not scale, hard to maintain, often monolithic Culinary art Fine food Home cooking Fast food and frozen food Basic ingredients like milk, bread, meat
  • 99. What CQRS is not? CQRS Basics/From CQS to CQRS
  • 100. Is CQRS for me? CQRS Basics/From CQS to CQRS What kind of problem do I try to solve ? • Collaborative domain • Locking the data without blocking the user • Read data scalability • Performance optimization • Complex workflows / Temporal data / Stale data
  • 101. There is more Aggregates • Validation • Uniqueness checking • Existence checking • Replaying of events (Event Sourced) Long running workflows Optimization
  • 102. Long running workflows CQRS Deep Dive Cooking How do I know if I need one? Difference between Saga and Process Manager?
  • 103. Client Order Aggregate Order Process Manager Stock Aggregate Payment Aggregate 2. OrderPlaced 3. Make reservation 4. ItemsReserved 5. Make payment 6. PaymentAccepted 7. OrderConfirmed 7. OrderConfirmed 7. OrderConfirmed

Notes de l'éditeur

  1. Explain what is monolith
  2. * RAP principle violated (Reused Abstraction Principle). Interface are not a guarantee of abstraction. We end up with one implementation per interface * Interfaces should be discovered and not invented.
  3. * RAP principle violated (Reused Abstraction Principle). Interface are not a guarantee of abstraction. We end up with one implementation per interface * Interfaces should be discovered and not invented.
  4. * RAP principle violated (Reused Abstraction Principle). Interface are not a guarantee of abstraction. We end up with one implementation per interface * Interfaces should be discovered and not invented.
  5. Explain what is monolith
  6. Explain what is monolith
  7. Where it should be used ? Where there is a value Concurrent domain / Performances optimizations
  8. It's about communication and not design
  9. Look no repositories At a high level, a context map can help you understand the integration between the different bounded contexts and the events involved
  10. Append only system
  11. Append only system
  12. Long running process: saga and process manager Optimization : command without messaging, commands in parallel