This document discusses CQRS (Command and Query Responsibility Segregation) and event sourcing architectures. It describes splitting commands and queries into separate pathways to improve scalability and performance. The key aspects covered are: - CQRS separates read (queries) and write (commands) operations to different data stores and models. This allows denormalized and optimized read models. - Event sourcing uses an event store to record the full sequence of events that describe changes to application state. Read models can be rebuilt from stored events. - Together, CQRS and event sourcing improve scalability, flexibility and auditability by modeling the domain as a sequence of immutable events rather than mutable objects.

1. CQRS +
EVENT SOURCING
Design to
build a bullet
proof
architecture

2. we are
Expertise
Quality
Respect
/studio
Agile
Big Data custom
CQRS Desktop Event
Sourcing Microsoft .NET C#
Scrum Software
development Training
© Pyxis Technologies inc.
Web

3. SPLIT COMMAND AND REQUEST
© Pyxis Technologies inc.
3

4. TRADITIONAL SYSTEM
Relational
database
Data updates
Business logic
CRUD
User interface
© Pyxis Technologies inc.
4

5. PROBLEMS
© Pyxis Technologies inc.
5

6. WHY ARE WE STILL DOING THIS?
© Pyxis Technologies inc.
7

7. WHY ARE WE STILL DOING THIS?
© Pyxis Technologies inc.
8

8. LEAP OF FAITH…
© Pyxis Technologies inc.
10

9. SPLIT COMMAND AND QUERY
TRADITIONAL SYSTEM
Relational
database
Data updates
Business logic
Commands
Requests
User interface
© Pyxis Technologies inc.
11

10. CQRS -
C O M M A N D A N D Q U E R Y R E S P O N S I B I L I T Y S E G R E G AT I O N
Relational
database
Data updates
Domain
Read model
Command
handlers
Requests
Commands
User interface
© Pyxis Technologies inc.
12

11. CALL TO ACTION
 Use verbs instead of nouns
 Ask yourself how the user will use your system
 Talk in domain language
 No simple data editing, more domain actions
 Submit commands
 Serializable message
 Imperative mode
 Well defined language
 Can a command be refused?
© Pyxis Technologies inc.
13

12. CQRS
 Commands
 Change system state
 Asynchronous (for better or worst)
 Requests






No system state change
Denormalized model
Distributable (Charding)
Scalable
At least 90% of system access
Performance
© Pyxis Technologies inc.
14

13. ARE WE THERE YET?
© Pyxis Technologies inc.
15

14. CQRS -
C O M M A N D A N D Q U E R Y R E S P O N S I B I L I T Y S E G R E G AT I O N
Relational
database
Data updates
Domain
Read model
Command
handlers
Requests
Commands
User interface
© Pyxis Technologies inc.
16

15. CQRS + EVENT SOURCING
Events
Denormalizer
Event Store
Event handlers
Service BUS
XML
SQL
Domain
HTML
Read model
Command
handlers
Requests
Commands
User interface
© Pyxis Technologies inc.
17

16. EVENT SOURCING






Model based on behavior not structure
Sequential and cumulative
Events can be played back
Append only
Any data structure can be built from events
Audit
© Pyxis Technologies inc.
18

17. EVENTS
 Rolling Snapshot
 Optimization
 Aggregate root
 Transaction scope
 Built from events
 Commands
 ApplyEvent
 Events
 Can’t fail
 No business logic
© Pyxis Technologies inc.
19

18. CQRS PIPELINE
Event store
User interface
Commands
© Pyxis Technologies inc.
Domain changes
Events
Denormalizer
Read models
20

19. THE END
 Remember
 Events are the only truth
 Domain is the heart of the system
 Read models are flexible and volatile
 Questions?
 Eric De Carufel
 eric@decarufel.net
 http://blog.decarufel.net
 http://pyxis-tech.com
© Pyxis Technologies inc.
21