3

Why event sourcing an entire system is a big mistake and considered an anti-pattern?

And what situation it's consider an anti-pattern?

Reference 1

Reference 2

Updated Question :

Still don't understand why build whole event-sourcing create big monolith? What if I use process manager is it still a monolith?

As Greg Young mentioned CQRS is not an top-tier architecture? What actually is top-tier architecture then?

What is the scope of entire system that Greg Young mentioned?

I don't see any mistake to have entire system as events. It's seem to be more consistence to use pure CQRS without mixed others concept (Except I have to).

  • Both of those articles say that doing so creates a monolith. If you're building a loosely-coupled system of services, a monolith is the last thing you want. – Robert Harvey Jul 9 '18 at 15:18
  • @RobertHarvey Then I don't quite understand why it's like creates a monolith? – b.ben Jul 9 '18 at 15:36
  • 1
    The infoQ article says this about it: "CQRS and Event sourcing are not top-level architectures and normally they should be applied selectively [in just a] few places." – Robert Harvey Jul 9 '18 at 15:58
  • 3
    It also says that "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." – Robert Harvey Jul 9 '18 at 15:59
  • Imagine all method calls turned into events. You can imagine what that does to code quality. It makes the code into an incomprehensible mess. I have actually seen this proposed in a German developer magazine. In the next issue there were angry reader comments for that :) – usr Jul 9 '18 at 17:29
7

Event Sourcing is hard and doesn't achieve a great deal on its own.

Also, People confuse Event Sourcing with a whole tonne of other things and find that they haven't achieved what they expected at the end of the project.

Having said that, I bet you can find articles on the internet saying anything is an anti-pattern with very little effort. These ideas tend to arrive, get hyped as the next best thing and then dropped by most people in very short order.

Make sure you understand what you are trying to achieve and why the pattern helps you before you decide to implement it.

3

Both of the articles you link to are quite clear ln where they see the problem with event sourcing: that it's a pattern that was designed for a specific task - creating transactional snapshot storage specifically for data that needs to have its change history easily recreated. But like many popular concepts, people ride the buzzword and try to apply it to everything - like making blockchain this and serverless that.

0

After learning CQRS and ES a while. I realise that using ES without having good reason enough is very big mistake.

I saw very little benefit from ES.

I'm not sure for the context that Greg Young mentioned. But by using ES we introduce very high complexity to implement, maintain and migrate.

We can easily cut ES off and left only CQRS+events, And gains almost every benefit from CQRS+ES.

Btw, CQRS itself need to be use with others application layers on top maybe rest or graph API. So CQRS/ES itself wont be top tier architecture.

Someone please correct me..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.