Why is whole system event sourcing an anti-pattern?

Question

I'm currently designing a new enterprise system. The system's purpose is to track, display, and notify employees of customer's interactions (i.e. events) with the company. Using an event source pattern to keep a ledger of all the customer interactions/events being collected seems like a very good fit, since all of our additional domain objects are derived from the stream of events. However, I came across an article saying that a whole-system based off of event sourcing is an anti-pattern. Why would this be?

https://www.infoq.com/news/2016/04/event-sourcing-anti-pattern

Answer 1

The article is indeed summarises the Greg's talk "A Decade of DDD, CQRS, Event Sourcing" at DDD Europe 2016.

I personally dislike the title of this summary since this is definitely not the point of Greg's talk. Basically, as usual, it depends.

When Greg talks about the system, he means the whole thing. This thing, in DDD terms, has a context map, with multiple bounded contexts in place. Usually, on this context map you can identify subdomains, where one or more can be in addition identified as core domain(s).

When you have your core domain - there will be a good fit for advanced techniques, would this be more traditional DDD tactical patterns like aggregates, or "fancier" stuff like Event-Sourcing. The implementation indeed need to be based on the context needs.

From what you describe, you have a good fit for Event-Sourcing. But you might think about other parts of your system, for example, customer/contact management and employee management. These details should come from somewhere. May be these are CRUD candidates? So if your core domain in this case is to track interactions between employees and customers, some sort of CRM, you can decide to build that part using Event-Sourcing and other parts of your system using less advanced techniques.

Remember putting all parts on the context maps anyway, including external systems, then you will see that the system word means in the article and the talk.

Answer 2

The article cites a talk by Greg Young. The relevant section is viewable here.

Young explains that CRUD hides "all kinds of crazy use cases", and gives correcting typos as an example.

He also points out that analysis can be more expensive in an event-sourced system.

In general, having immutable events as the source of truth for a given part of a system, separated from read models, carries costs and should not be adopted blindly.

Young suggests that "something more like event-driven" would be a top-level architecture rather than CQRS/event sourcing.