Cqrs and event sourcing in azure
•Download as PPTX, PDF•
2 likes•2,416 views
CQRS and Event Sourcing are popular architectural patterns that allow you to build effective event-driven micro-services. The basic idea of these patterns is to record each event that changes the state of the domain model into the event-storage. This approach allows you to reduce service latency for any data scale, as well as be able to restore the system without losing any data.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cqrs and event sourcing in azure
Similar to Cqrs and event sourcing in azure (20)
More from Sergey Seletsky
Recently uploaded
Recently uploaded (20)
Cqrs and event sourcing in azure
- 1. CQRS and Event Sourcing in Sergiy Seletsky Senior Solution Architect
- 2. Agenda • Pain points of traditional architecture • CQS and CQRS theory • Event Sourcing • DDD and Event-driven microservices • Reference implementation for .NET • Q&A
- 4. Application Design Pain Points • Scalability of System is by larger and larger RDBMS • Surprise, surprise! • Persistence means ‘save the Current State’ of the domain model • Query concerns are at odds with Transactional concerns • System audit adds extra complexity • Issues with complex data schema versioning • more…
- 5. Domain Modeling Pain Points Business Rules only exist in user’s heads Converting Domain Objects to DTOs (and back again!) Domain Object Persistence Lazy vs. Eager Fetching Optimizing Domain for efficient Queries Setter/Getter Anti-Pattern Tests are (often) brittle more…
- 6. Business Pain Points Must know what business questions we want to ask up front Optimizing for Queries and Optimizing for Transactions are tied together (and very expensive) Evolving Requirements is hard/expensive more…
- 7. What is CQS & CQRS?
- 8. Command-Query Separation Command-Query Separation (CQS) states that 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. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects. Query - returns data and not apply any changes Command - apply changes and not returns data, only result of execution
- 9. SQS via ISP (Interface Segregation Principle)
- 10. CQRS Command-Query Responsibility Segregation • The CQS principles applied to your domain modeling and system architecture • Enable each element of your architecture to be optimized for a single responsibility • Decomposition for your architecture rather than just for your objects
- 12. LAN/WAN Slicing and Dicing our Architecture Application Services Domain Object Domain Object Domain Object Domain Object Client Remote Services RequestDTO ReturnDTO Command ACKReturned RDBMS Client Server WriteRead
- 13. LAN/WAN Refactoring our Architecture Application Services Domain Object Domain Object Client Remote Services RequestDTO ReturnDTO Application Services Command ACKReturned WriteRead Light-Weight Query Services RDBMS Domain Object Domain Object Persistence Persistence Remote ServicesRemote Services Eventually
- 14. Read StorageEvents Storage APIs Write Model Read Model Events Command Query CQRS Command-Query Responsibility Segregation
- 15. Write Model Write Model Events Command Handler Event Applier EventBus/EventStore Domain Model Events REST commandBus.Send( CreateJobProfile(jobProfile) ); [CommandHandler] public Task Handle(CreateJobProfileCommand command) { //check if exist repository.FindEntity(); event = new JobProfileCreated(command.entity); RaiseEvent(event); [EventHandler] public void HandleCreated(JobProfileCreated event) { entity.Apply(event); storage.Save( entity ); } CmdBus
- 16. Read Model Write Model EventBus/EventStore Event Handler Domain Model Events Materialized Repository REST [EventHandler] public void Handle(JobProfileCreated event) { entity = new CareerMatrixQueryModel( event.Entity ); //extra projections happened here storage.Save(entity);
- 17. As many read models as you want With No performance degradation UI Write Model Events Command Query Read ModelRead ModelRead Model
- 18. C PA CAP Theorem: onsistency, vailability, artition-Tolerance; pick any two! Write Read Scaling of Distributed Systems C A P
- 19. Event Sourcing
- 20. Event sourcing The basic idea behind Event Sourcing is quite simple. A persistent actor receives a (non-persistent) command which is first validated if it can be applied to the current state. Here validation can mean anything from simple inspection of a command message's fields up to a conversation with several external services, for example. If validation succeeds, events are generated from the command, representing the effect of the command. These events are then persisted and, after successful persistence, used to change the actor's state. When the persistent actor needs to be recovered, only the persisted events are replayed of which we know that they can be successfully applied. In other words, events cannot fail when being replayed to a persistent actor, in contrast to commands. Event sourced actors may of course also process commands that do not change application state such as query commands for example.
- 22. Event Sourcing advantages • Events are immutable and can be stored using an append-only operation. • Events are simple objects that describe some action that occurred • Events typically have meaning for a domain expert • Event sourcing can help prevent concurrent updates from causing conflicts because it avoids the requirement to directly update objects in the data store • The append-only storage of events provides an audit trail that can be used to monitor actions taken against a data store • The event store raises events, and tasks perform operations in response to those events.
- 24. Domain boundaries is a key to success
- 25. Define cross-boundary domain events Event storming
- 26. The Art of Scalability CQRS & ES Infinite Scale Unlimited scalability
- 27. IntelliGrowth – Serverless Cloud Architecture
- 29. Questions?
- 30. Reading Domain Driven Design Eric Evans Building Microservices Sam Newman Exploring CQRS and Event Sourcing Dominic Betts
- 31. Resources • Greg Young - Building an Event Storage • Microsoft - Exploring CQRS and Event Sourcing • Greg Young - CQRS & Event Sourcing • Lorenzo Nicora - A visual introduction to event sourcing and cqrs • Greg Young - A Decade of DDD, CQRS, Event Sourcing • Martin Fowler - Event Sourcing • Eric Evans - DDD and Microservices: At Last, Some Boudaries! • Martin Kleppmann — Event Sourcing and Stream Processing at Scale • Julie Lerman - Data Points - CQRS and EF Data Models • Vaughn Vernon - Reactive DDD: Modeling Uncertainty • Mark Seemann - CQS versus server generated IDs • Udi Dahan - If (domain logic) then CQRS, or Saga? • Event Store - The open-source, functional database with Complex Event Processing in JavaScript • Pedro Costa - Migrating to Microservices and Event-Sourcing: the Dos and Dont’s • David Boike - Putting your events on a diet • DDD Quickly • Dennis Doomen - The Good, The Bad and the Ugly of Event Sourcing • Liquid Projections - A set of highly efficient building blocks to build fast autonomous synchronous and asynchronous projector
- 32. Thank you! Centers of Excellence