Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Cqrs+es
Semelhante a Cqrs+es (20)
Último
Último (20)
Cqrs+es
- 1. CQRS & Event sourcing Event sourcing Event sourcing
- 2. About me • Lifetime hacker • Explorer of technologies • Polyglot programmer • @sorenmat • https://github.com/sorenmat
- 3. CQRS + ES • What is CQRS • What is Event sourcing • Demo
- 4. Typical N-TIER architecture pros • Well known • Accepted by management • Lots of resources • Lots of frameworks
- 5. Typical N-TIER architecture cons • Complex • Business logic bleeds through layers • Validation everywhere • No provable audit trail • No concept of change • Caching • Hard to scale No concept of change -> class change customer state means what ever hibernate says No concept of change -> class change customer state means what ever hibernate says
- 7. CQRS to the rescue CQRS W TF !!
- 8. CQRS to the resuce Command Query Responsibility Segregation W TF !!
- 9. CQRS Based upon Bertrand Meyer’s Command Query Separation (CQS) principle: “every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer” (Meyer)
- 10. Why CQRS ? • Scalability • Reduced complexity • Flexibility • Focus on the business Making commands, gives focus on the business Making commands, gives focus on the business
- 11. CQRS in the making • Let’s focus on the language - AddItemToBasket vs UpdateBasket • Task based UI • We need to separate reads from writes • Lets split our architecture
- 12. CQRS Structure
- 13. Commands • Commands ask the system to do changes • Commands can fail • State intent • Can be asynchronous
- 14. Stale data • Async - ooohh nooes • Eventual consistency • How stale must stale data be ? • How stale is your data ? • Design for it
- 15. Read Models • Build for the “UI” • Optimized for the use case • Comes in all shape and forms
- 16. Event sourcing
- 17. Don’t save the result, save the steps !
- 18. Event sourcing •Analysis and access to historic data •Provable Audit log •Flexibility to create new views or queries (CQRS) •Replaying events for debugging •Enables Memory Image
- 19. Aggregates •A boundary for transactional consistency •Only one aggregate can be modified in a single transaction •A cloud of related objects, both entities and value objects •Only the root can be referenced from outside the aggregate
- 20. Aggregates •Must ensure that its state never ever violates its business invariants •Between the boundaries, there can only be eventual consistency
- 21. Aggregate example • Aggregate are the “base” of the model • Order is the aggregate root • Order has an addLineItem method
- 22. Event stream •Every state-modifying operation on an aggregate results in an event •The actual state change is achieved by applying the event to the aggregate OrderCreatedOrderCreated OrderLineItemAddedOrderLineItemAdded OrderLineItemRemovedOrderLineItemRemoved OrderLineItemAddedOrderLineItemAdded
- 23. Events • Represents the state of the aggregate • Passed tense, can’t be undone • Events never changes
- 24. Event sourcing • Conflict merging • Easy integration • Expose events through feed • Very testable
- 25. Event store • Stores all events • Append only • Single source of truth
- 26. Event store • Simple in design • Few operations • append • getAllEvents • getEventsForAggregate
- 27. Event Store • Performance can be gained through snapshots • Serialize the aggregate with an eventId
- 28. Summary
- 29. Pros and Cons • Great performance • Very scalable • Auditing • Easy to integrate • Testable • Tech free • Not well known • Different mindset
- 30. DEMO
- 31. Our model