A Whole System Based on Event Sourcing is an Anti-Pattern
Command Query Responsibility Segregation (CQRS) was never meant to be the end goal of what we are trying to achieve, it is a stepping stone towards the ideas of Event sourcing, Greg Young stated in his presentation at the Domain-Driven Design Europe conference earlier this year. He noted though that just applying CQRS by separating reads from writes and targeting the same database is still a valuable pattern and he has seen many teams built systems that way.
Looking back at a decade of Event sourcing, Young has seen many breakthroughs when applying it to new domains, not only the typical high transaction write domains like finance and gambling. Modelling events forces a behavioural focus instead of on structure, which can be useful especially when dealing with domain experts coming from a legacy world. Modelling events also forces a temporal focus, with time becoming a crucial factor in a system. Thinking temporally, how things correlate over time, often bring forward core domain knowledge.
A great success during the last years has been Event storming. Young notes that there is more than one style, referring to the style used by Alberto Brandolini with an exploratory way of finding the problems in a domain. Another style by Young himself focus only on one process, the purpose being to discover service boundaries. He expects Event storming process to be more formalized in the future and encourages people to look more into it.
The single biggest bad thing that Young has seen during the last ten years is the common anti-pattern of building a whole system based on Event sourcing. That is a really big failure, effectively creating an event sourced monolith. CQRS and Event sourcing are not top-level architectures and normally they should be applied selectively just in few places.
The last problem Young mentions is the lack of Process managers. Building a system with many services each directly subscribing to events from other services can make it very hard to understand what the system actually does. Finding the overall process can be quite difficult without going through the code in each service. Young notes that Process managers are difficult but believes that the best explanation is found in the Enterprise Integration Patterns book.
Looking into the future Young believes we will see more functional programming along with event sourcing. He notes that even though event sourcing often is tied into object orientation it’s a purely functional model making it fit very well with functional code and he thinks we will see an increasing amount of functional code on top of event sourced systems.
Young also believes there will be more use of Process managers, especially with more and more use of Actors since they for him make perfect Process managers. He describes an Actor framework as a Process manager framework.
Next year’s Domain-Driven Design Europe conference is scheduled for end of January 2017.
Been there, done that
applied selectively just in few places."
A few years ago I was naive to implement User/Roles Management using Event Sourcing. The good part was that I realized quite soon it was a mistake.
On the other hand, if User/Roles Management is the core domain of the business application, it makes sense to use Event Sourcing. The conclusion is that Event Sourcing should be used where it matters for the business and where behavior is important.
Another gotcha is Eventual Consistency. Treat this with care. The purists will tell you that there is no strong consistency in the real world. You will surely find cases when you actually need strong consistency and then you will lose valuable time finding work around in order to impose or simulate it.
This may be another criteria for choosing CQRS.
On the UI side, solutions like Redux with global immutable client-side store that changes based on actions (events) and unidirectional data flow, fit very good to the event sourcing and does not require nasty workarounds for eventual consistency.
How "whole system" eventually translates to "monolith"?
If the team has solid foundations for building event-sourced systems with tools and practices in place, using the same pattern in most (not all, of course) situations does not hurt. But this choice is rather secondary, after doing proper context mapping and finding service boundaries. What exactly is used inside the service is not that important from the "whole system" perspective.
Re: Eventual consistency