BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

A Whole System Based on Event Sourcing is an Anti-Pattern

| by Jan Stenberg Follow 6 Followers on Apr 26, 2016. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Been there, done that by Adrian Ivan

"CQRS and Event sourcing are not top-level architectures and normally they should be
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.

Eventual consistency by Alexey Zimarev

More often than not, "actually need strong consistency" means "my client is designed in a way I have to have consistent reads". For example, when a user input need to reflect in a list that is read from persistent store. If this is done via CQRS, the read model is not updated immediately and the list does not show user's input. However, these situations do not imply transactional consistency on the read side, it just says "I design my UI this way", not "my business works this way". We as developers are spoiled by consistent storages and expect everything to be consistent even if this hearts performance. The number of cases when absolute consistency is required by the business is very very limited.

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"? by Alexey Zimarev

If my "whole system" is a number of services, each of those represents a separate bounded context, how does it matter, which pattern do I use inside each service?

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 by Adrian Ivan

The majority of devs/stake holders are trapped in the "transactional" model of thinking. I clicked it, it must be there. People like things to happen immediately. The effort to simulate this is pretty big and referring to the article I just confirm that the decision to adopt this patter cannot be taken lightly.

Re: Been there, done that by Gone Drone

Oh, hey. Guess who else has implemented a role-based access control system in Event Sourcing...

What saved me in the long run was flattening the control hierarchy (roles are now non-hierarchical, i.e. there is no vertical inheritance of ACLs), and modelling each resource to be accessed, instead of each role that wields ACLs, as a separate entity. We called that process the "tree inversion", because we actually had to migrate a 70MB monolithic JSON tree into separate entities and invert the relation that subjects exposed to objects (now, each entity holds IDs of roles that can access it).

It works to this day, but there was not much added value in making it event sourced, to be honest, as the shape of the solution (being based on ACLs) is not much different from an ordinary SQL table.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT