You generally have to create compensating events to “undo” something. Nor would that actually even make much sense. With Event Sourcing, since the events are in an immutable log (event stream), you can’t just “update” an existing event. While I don’t think the concept of Event Sourcing is difficult, how you deal with an immutable log (event store) is very different than just recording the current state.Īn example of this is when using a relational database if you needed to “fix” data, you’d simply go and write an UPDATE statement to update records in your database. The biggest pitfall is how different the concept can be to developers who have only ever done CRUD and only ever recorded the current state. Best Practices and Pitfalls when Event Sourcing? What you can do in this situation is make sure any old event can be upconverted at runtime to the new event. The difference is that you cannot backfill and update old events in an existing stream. If it’s not null and has a default value the situation is still the same as a relational database. You’d need to deal with the value being null. With event sourcing, making a new property on an existing event nullable is exactly the same. If you were adding a new column to a table, you would either need to make the column nullable or give it a default value and then possibly backfill existing data. I often like to compare this to a relational database. The definitive answer to versioning is Greg Young’s Versioning in an Event Sourced System eBook. No Software Architecture Q&A on this Blog/YouTube could happen without a few questions about Event Sourcing. How to handle versioning when Event Sourcing? If you’re using CQRS, you’d have events such as CustomerAdresssChanged and CustomerDiscountRateIncreased. If you wanted to publish an event based on CRUD, you would have very generic events such as CustomerUpdated. Because commands are explicit, you can then infer various events to be published from those commands. You’re not “updating a customer” but rather you’re using explicit commands such as ChangeCustomerAddress or IncreaseDiscountRate. With CQRS, all your commands are making those state changes explicit. For example, if you’re performing an Update to a customer why is that happening? Did their address change? Did their discount rate change? With CRUD based approach, you don’t know exactly, you’d have to imply it based on the change being made. With CRUD, when you’re making state changes via Create, Update, Delete, you aren’t capturing explicitly why it’s occurring. When should I choose CQRS over CRUD based “RESTful” endpoints?Ĭhoose CQRS over CRUD when you want to be explicit. Event Choreography is having all services consume and produce events that ultimately fulfill the long-running business process.Ĭheck out my post on Event Choregrophay and Orchestration for more. And when I say long-running business process, that could mean milliseconds to weeks.Īn alternative to a Saga is using Event Choreography, which removes the centralized logic of orchestration. The saga is a centralized place to handle the workflow of a long-running business process. Since there can be failures, the saga is responsible for handling failures by sending compensating actions to the appropriate services. It’s responsible for coordinating a long-running business process between multiple services where there are no distributed transactions. Is the saga an anti-pattern since you have a transaction spanning multiple bounded contexts? So my answer to this question is nothing is different between the two. And because they are independent communication is done in a loosely coupled fashion via an Event or Message Driven Architecture. You aren’t sharing behaviors or data between services. Services should own a set of business capabilities and the data behind those capabilities. Bounded Contexts are about defining boundaries. The Bounded Context portion of the definition is from Domain Driven Design. In my mind, SOA was always about being loosely coupled, however that may not have been how the general developer community understood it at the time. Loosely coupled implying Event Driven Architecture. If I dissect that definition, Service Oriented Architecture that’s loosely coupled. Loosely coupled service oriented architecture with bounded contexts. The definition of Microservices that I generally use is from Adrian Cockcroft: ![]() The answer to this question really depends on your definition of both SOA and Microservices. ![]() I believe it’s because of how I present Event Driven Architecture in relation to Microservices. I get this question often and I was expecting it for this Software Architecture Q&A. What is the difference between SOA and Microservices? Video can’t be loaded because JavaScript is disabled: Q&A: Messaging, CQRS & Event Sourcing! ()
0 Comments
Leave a Reply. |