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.