"Event Sourcing", along with "CQRS" (Command Query Responsibility Segregation), have recently become trending terms, and now there is so much theory, blog posts and talks about them. However, most of these deal with the problem starting from an utopian assumption: having to write a project from scratch (greenfield), but at the same time with a high domain complexity right from the start, enough to justify the use of a complex technique like event sourcing and CQRS, which carry a fair amount of inherent complexity. But the reality greatly differs: projects are born from small and simple prototypes, and they accumulate complexity only with time and the growth and evolution of specifications and features. This talk is a case history in which I will tell you (with little theory and a lot of practical examples) how we decided to **add event sourcing to an already existing project** (without eradicating the rest or rewriting it), to **solve a specific problem** (reporting and its historization) for which this methodology proved to be the **perfect solution**.


Comments are closed.

I really liked the trade-offs mentioned and the rationale behind doing some parts not the "pure" EventSource way. It showecased clearly a deep understanding of the Business needs and a practical approach to fulfilling them. In contrast to most CQRS/ES talks, that focus on the theory, this talk focusses on the actual implementation and problems they encountered. Good presentation style, nice pace. My only advice would maybe be to remove some text from the slides and just keep the ones that underline your thought train or point.