1. CQRS/ES AND FRIENDS
Possibly distributed systems... intentionally

3. WHY DO WE NEED YET ANOTHER SHINY?
 Is this an Architecture? No: a bunch of patterns
 Sorry I don’t cook
 Less how should it be, more what should it do

5. WHY DDD IS RELEVANT
 Ubiquitous language
 Bounded contexts
 Aggregates
 If you are looking for intention, there is a way to
persist it
 Legacy systems anyone?

6. IF I WAS TRYING TO LEARN CQRS NOW

7. CQRS/ES
 CQRS: “Separate command messages that
change state from query messages that read
state.”
 Event Sourcing: Capture changes to an
application state as a sequence of events.

8. AND FRIENDS
 Eventual Consistency
 Messaging

9. QUERY
 Query Side: asking a question should not change
the answer.

10. TASK BASED UIS

11. COMMAND
 Tell the system what to do
 Has a well defined intention

12. EVENT
 Occurrence
 If using messaging, possibility of integration.

14. CONSEQUENCE
 Compensating actions -> there is no big eraser
here
 Automatic audit log
 Since there are no queries to read… the
aggregate roots have fewer relationship and their
boundaries are better defined

15. AN EXAMPLE
1. Add Item to cart
2. The product is not in stock

16. THANKS
 Andrea Magnorsky
 @silverspoon
 www.roundcrisis.com
I wantz sleeps, its
Caturday