The Good, The Bad and the Ugly of Event Sourcing
•Descargar como PPTX, PDF•
7 recomendaciones•868 vistas
In 2009, I first learned about Event Sourcing and Command Query Responsibility Seggregation (CQRS) at a training Greg Young gave in Utrecht, The Netherlands. I remembered to be awed by the scalability and architectural simplicity those styles provided. However, I also remembered the technical complexity that comes with it. In 2012, I was in charge of transitioning a CQRS-based system to Event Sourcing. I knew it would be non-trivial, but boy was I in for a surprise. So over the last four years I've experienced first-hand how a large group of developers had to deal with the transition. It's a brilliant solution for high-performance or complex business systems, but you need to be aware that this also introduces challenges most people don't tell you about. In this talk, I'd like to share you some of the most powerful benefits of ES, but also show you the flipside of the coin and cover some of the smaller and bigger challenges you'll run into it. Again, I love it and would apply it again without any doubt, but I really want you to understand the trade-offs before you jump on the Event Sourcing train.
Recomendados
Recomendados
Más contenido relacionado
Más de Dennis Doomen
Más de Dennis Doomen (20)
Último
Último (20)
The Good, The Bad and the Ugly of Event Sourcing
- 1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
- 3. Web Application Command Service Query Processor ChangeUser EmailHandler User Unit of Work User Projector DAL Query Handler Read DB Write DB ChangeUserEmailCommand Execute query Get<User>(identity) Invoke method Event Store Load(events) Apply Get changes Dispatcher Events Handle(UserEmailChangedEvent) Submit changes History Query Language / SQL Dennis Doomen | @ddoomen | The Continuous Improver
- 4. The Good
- 5. Domain Event Store Events App RDBMS Events Projection EventsProjection Projection Projector Optimized for specific queries Separate projections database NoSQL Projector Projection-specific storage Projector HTML Raw SQL, Dapper or OR/M Run asynchronously Great for sharding Dennis Doomen | @ddoomen | The Continuous Improver
- 6. Events Transaction 6 Transaction 5 Transaction 4 Transaction 3 Transaction 2 Transaction 1 Temporal Projector Read Store Time Projected until this point Immutable, thus auditable and SOX compliance Dennis Doomen | @ddoomen | The Continuous Improver
- 7. Domain Event Store Events App Events Projection EventsProjection Projection Projector Application projections RDBMS Reporting Projector Traditional reporting model Asynchronous OLAP Dennis Doomen | @ddoomen | The Continuous Improver
- 8. StreamId: User-Dedo, Rev: 5 Persisted State Changes StreamId: User-Dedo, Rev: 4 GrantedRoleEvent PasswordChangedEvent StreamId: User-Dedo, Rev: 4 StreamId: User-Dedo, Rev: 3 UserCreatedEvent GrantedRoleEvent PhoneNumberAddedEven t PasswordChangedEvent StreamId: User-Dedo, Rev: 5 RoleRevokedEvent StreamId: User-Dedo, Rev: 6 GrantedRoleEvent Time StreamId: User-Dedo, Rev: 7 PasswordChangedEvent Dennis Doomen | @ddoomen | The Continuous Improver
- 9. Changes 1 2 3 6297 6298 6298 Query Data Documents Groups Users Objects Folders User Interface Changes Queries Changes 1 2 3 6299 6300 6301 Query Data Documents Groups Users Objects Folders User Interface ChangesQueries Node Node Replication Process Dennis Doomen | @ddoomen | The Continuous Improver
- 10. Events Aggregate Root Entity Entity Value Object Aggregate Root Aggregate Root Aggregate Root Entity Value Object Value Object Dennis Doomen | @ddoomen | The Continuous Improver
- 11. The Bad
- 13. • Designing your domain based on ownership • Relying on eventual consistent projections • Bad choice in functional keys (e.g. username vs ID) • Running business logic after an domain event is raised • Domain-specific value types in events • Fast growing aggregates
- 15. First • Ask the difficult questions about consistency • Understand the real world Then use these guidelines • Driven by invariants, not composition • Only consistent within aggregate • Small aggregates • Reference by identity.
- 17. public class Order { private Status status; public void Cancel() { if (status == Status.InProgress) { Apply(new OrderCanceledEvent()); } } private void When(OrderCanceledEvent e) { status = Status.Canceled; } } In single classes Dennis Doomen | @ddoomen | The Continuous Improver
- 18. public partial class Order { private Status status; public void Cancel() { if (status == Status.InProgress) { Apply(new OrderCanceledEvent()); } } } In partial classes public partial class Order { private void When(OrderCanceledEvent e) { status = Status.Canceled; } } Dennis Doomen | @ddoomen | The Continuous Improver
- 19. public class Order { private OrderState state; public void Cancel() { if (state.Status == Status.InProgress) { state.Apply(new OrderCanceledEvent()); } } } In separate classes internal class OrderState { public Status Status { get; set; } private void When(OrderCanceledEvent e) { Status = Status.Canceled; } } Dennis Doomen | @ddoomen | The Continuous Improver
- 20. Risk Assessment Level Changed Risk Assessment Team Member Removed Risk Assessment Team Member Removed Risk Assessment Level Demoted Versus Dennis Doomen | @ddoomen | The Continuous Improver
- 21. Assembly AvSol.Domain.dll Namespace AvSol.Domain.RiskAssessments Type RiskAssessmentLevelChanged Assembly AvSol.ThreadAssessment.dll Namespace: AvSol.ThreadAssessment.Risks.Domain Type RiskAssessmentLevelDowngraded Dennis Doomen | @ddoomen | The Continuous Improver
- 22. The Ugly
- 23. Domain Event Store Events App Query Store Data Access Projectors Events API Controller Projections Events Figuring out the right testing scope
- 25. Rebuilding time with large databases • Side by side rebuilding (a.k.a. blue- green) • Functional archivability and archiving • Projection tracking and prediction • Clear separation between critical and auxiliary data -> prioritization • Partitioning.
- 26. Dynamic rebuilding • After bugs, schema changes, etc • Manual or automatic (e.g. hashes) Projection consistency • Idempotency of projections • Projection autonomy results in more duplication.
- 27. Projections that crash • Column constraints (e.g. data truncation) • Changes in data invariants (null vs non-null in event versions) • Unexpected projection dependencies • Partial replays.
- 28. Projection dependencies • Synchronous -> asynchronous and existing bugs • Assuming order of events Bugs • Causing duplicate child records • Causing large event streams • Incorrect caching strategy (e.g. on lookups) • Identity case-sensitivity • Incomplete SQL-backed event store reads.
- 29. Tips & Tricks
- 30. • Liquid Projections – Designed as a library – Promotes fully autonomous projections – Local tracking – ETA calculations • NEventStore • GetEventStore • Apache Kafka?
- 32. • The Good, The Bad and the Ugly of Event Sourcing http://www.continuousimprover.com/search/label/event%20sourcing • Effective Aggregate Design (Vaughn Vernon) http://dddcommunity.org/library/vernon_2011/ • Liquid Projections https://github.com/LiquidProjections • Distributed Event Sourcing (Slides) http://www.slideshare.net/dennisdoomen/building-occasionally- connected-applications-using-event-sourcing • Data schema changes in an event sourced system (paper) http://files.movereem.nl/2017saner-eventsourcing.pdf
Notas del editor
- Event/Format structure: primitive types only, self-describing