I very much agree with your conclusion! In my company I’m working at, we use event sourcing only for audit and investigation purposes as you mentioned. We still keep records in the “traditional” crud way (we don’t build current state from event sourcing )
CQRS can also be strong consistancy, it depends on the architecture of the app, for instance, only replying in the event of completing the data projection write. It can also be done with little delay, pretty much inconceivable to the user and has little effect on the system. It is also not forbidden to modify an event, it's just not recommended due to increased complexity and time burden as it can have a ripple effect for any event that comes after. I would actually recommend using event sourcing, simply due to the fact that you can trade complexity from other things, like database design for new services and features. This is because it is a 100% code first approach. It also matches more closely to a business process, meaning process to code is a lot more simple as you just copy the process rules and can't be accused of not following the business rules.
Thank you very much for the feedback! I do have a question (end of this answer). I agree that within the same process, it is possible to have strong consistency very easily. I also agree that you can modify an event. However, I feel you'd be bending the original definition quite a lot since the immutability of events is what gives stronger auditing guarantees compared to other paradigms. If you allowed the event log to be rewritten, it would lose value in that sense. However, it is always a question of what matters the most in your application. The complexity topic is the bit where I am the most torn. I have read in multiple texts that when modeling events (e.g. in event storming) it is easier to keep a direct mapping with the business rules. I can see that. The bit where I get lost is that in my mind, the complexity is shifted further where we materialize events into projections / model / views. Isn't it typical domain modeling still necessary there?
@@MarcoLenzo It can be done easily even if it is not in the same process, I do it all the time as it doesn't take enough time to warrent eventual consitancy, it's a little more work, though it is worth it for strong consistancy. That is why I said that it is not recommended. Just outright saying it is strict is confusing to beginners, in reality it is just best practice. Projections don't have to be a strict structure, it can still be in the format of a payload, so modeling isn't needed still. This will also mean no mapping to an object before returning. Though I may add you can still map and query quite easily with little overhead, but the point of projections is not to have joins or complex queries due to the overhead they bring.
Do you have experience with event sourcing and CQRS? Would you recommended it to a fresh software development team? Let us know! 🤓🤓🤓
I very much agree with your conclusion! In my company I’m working at, we use event sourcing only for audit and investigation purposes as you mentioned. We still keep records in the “traditional” crud way (we don’t build current state from event sourcing )
Thank you very much for taking time to give feedback 🙏
Priceless. Thank you so much, Marco, for your efforts
Thank you Stanislav 🙏
Good short and still comprehensive summary of this pattern. I will definitely consider your pros and cons in our architecture. Thanks Marco!
Thank you Marcelo!
Thanks, Marco. The concepts are mentioned clearly and deftly. ✌
Thank you! 🙏
Really god information.. totally agree with your conclusion...
Thank you
Great video. Thanks for the precise explanation!!
Thank you!
Thank you Marco, great video as always
Thank you Jose! 🙏
CQRS can also be strong consistancy, it depends on the architecture of the app, for instance, only replying in the event of completing the data projection write. It can also be done with little delay, pretty much inconceivable to the user and has little effect on the system.
It is also not forbidden to modify an event, it's just not recommended due to increased complexity and time burden as it can have a ripple effect for any event that comes after.
I would actually recommend using event sourcing, simply due to the fact that you can trade complexity from other things, like database design for new services and features. This is because it is a 100% code first approach. It also matches more closely to a business process, meaning process to code is a lot more simple as you just copy the process rules and can't be accused of not following the business rules.
Thank you very much for the feedback! I do have a question (end of this answer).
I agree that within the same process, it is possible to have strong consistency very easily.
I also agree that you can modify an event. However, I feel you'd be bending the original definition quite a lot since the immutability of events is what gives stronger auditing guarantees compared to other paradigms. If you allowed the event log to be rewritten, it would lose value in that sense. However, it is always a question of what matters the most in your application.
The complexity topic is the bit where I am the most torn. I have read in multiple texts that when modeling events (e.g. in event storming) it is easier to keep a direct mapping with the business rules. I can see that. The bit where I get lost is that in my mind, the complexity is shifted further where we materialize events into projections / model / views. Isn't it typical domain modeling still necessary there?
@@MarcoLenzo It can be done easily even if it is not in the same process, I do it all the time as it doesn't take enough time to warrent eventual consitancy, it's a little more work, though it is worth it for strong consistancy.
That is why I said that it is not recommended. Just outright saying it is strict is confusing to beginners, in reality it is just best practice.
Projections don't have to be a strict structure, it can still be in the format of a payload, so modeling isn't needed still. This will also mean no mapping to an object before returning. Though I may add you can still map and query quite easily with little overhead, but the point of projections is not to have joins or complex queries due to the overhead they bring.
Understood! Thanks a lot for the insight
Another great video! Great and concise explainer on Event Sourcing and CQRS, with a sprinkle of Magic Architecture Dust 😂
Lol
This is gold!
Too kind!
good video
🙇 Thank you