[alex-lawrence]

In one project, where we could have done otherwise, we went consciously full Event Sourcing. In another project, the Domain Model was inherently event-based. In my book, the Sample Application first persists domain objects and is later refactored towards Event Sourcing.

While I read about the possibility of doing both at the same time, I never encountered this practice in a project. How I see it, there is always only one source of truth. If you apply Event Sourcing, it is the event log. Any other representation should be seen as derivation/projection.

The one long-term project where we applied Event Sourcing showed quite some challenges you can face with this pattern. For me, the most challenging aspect is the versioning of an event-sourced system. When the Domain Model evolves, it might necessitate changes to events or the introduction of new ones. Greg Young even wrote a book on this topic: https://leanpub.com/esversioning (I haven't read it though).

[JCDenton2052]

Can you tell me a bit a more about the long-term project where you applied full ES? What kind of domain/business context informs this decision?

I am aware of the costs of the approach, but would like to know the real world problems it solved for you.

[alex-lawrence]

Please note that I have limited experience with domains where Event Sourcing is without a doubt the weapon of choice. Hope my input still helps. Maybe there are other people that can give more qualified input on that. In the end, I am not trying to advocate for the pattern.

The project was about building a SaaS for structured meetings, both for on-site and remote use. It involved topical areas such as collaboration, moderation and presentation. The model defined that every meeting consists of six steps, where each is facilitated with one specific method (out of multiple). There were also additional functionalities such as a collaborative whiteboard and audio/video communication.

I briefly mentioned this in another comment: With regard to software architecture and pattern use, the project is a negative example. CQRS and Event Sourcing was prescribed on a system level. Regardless of conceptual/technological boundaries, every part made use of it. This decision was by no means reinforced with domain- or business-specific arguments. However, for us as developers, it was a great learning opportunity.

In terms of significant benefits for specific contexts, I can only think of the whiteboard part. However, even for that, it is about a feature we never got to implement. At some point, we wanted to add a "Undo" functionality. With Event Sourcing, you can simply append events that represent the reversal of previously persisted state transitions.

Independent of domain-specific aspects, I experienced three universal benefits. I hate to say it, but one was in fact reporting. Another benefit is the increased possibility to solve concurrency conflicts in a domain-specific way. Third, an event-sourced service is an ideal foundation for sending notifications, such as when publishing Domain Events. In the project, it helped us to build a real-time reactive User Interface. Of course, I'm not saying you necessarily need Event Sourcing for that.