CQRS without Event Sourcing - what are the drawbacks?

Question

Besides missing some of the benefits of Event Sourcing, are there any other drawbacks to adapting an existing architecture to CQRS without the Event Sourcing piece?

I'm working on large application and the developers should be able to handle separating the existing architecture into Commands and Queries over the next few months, but asking them to also add in the Event Sourcing at this stage would be a HUGE problem from a resourcing perspective. Am I committing sacrilege by not including Event Sourcing?

Moureaux

Was my answer helpful? Did I miss something? Feel free to ask if something still is unclear. – Trimurti

Answer 1

Event Sourcing is optional and in most cases complicates things more than it helps if introduced too early. Especially when transitioning from a legacy architecture and even more when the team has no experience with CQRS.

Most of the advantages being attributed to ES can be obtained by storing your events in a simple Event Log. You don't have to drop your state-based persistence, (but in the long run you probably will, because at some point it will become the logical next step).

My recommendation: Simplicity is the key. Do one step at a time, especially when introducing such a dramatic paradigm shift. Start with simple CQRS, then introduce an Event Log when you (and your team) have become used to the new concepts. Then, if at all required, change your persistence to Event Sourcing and fire the DBA ;-)

Trimurti

Do you know any framework that helps for doing cqrs without the event sourcing part ? – Puffy

@remibourgarel I have heard very good things about lokad cqrs, from some very knowledgeable people: github.com/Lokad/lokad-cqrs – Florrieflorry

See also InfoQ - The Complexity That Is Hidden in Microservices and Event Sourcing – Metagalaxy

Why do you think it will become the next logical step? – Silvery

Answer 2

I completely agree with Dennis, ES is no precondition for CQRS, in fact CQRS on its own is pretty easy to implement and has the potential to really simplify your design.

You can find a smooth introduction to it here

Secondly what benefits does CQRS on its own bring to the table?

• Simplifies your domain objects, by sucking out all the query concerns
• Makes code scalable, your queries are separated and can be easily tuned
• As you iterate over your product design you can add/remove/change individual commands/queries, instead of dealing with larger structures as a whole (e.g. entities, aggregates, modules).
• Commands and queries produce a well-known vocabulary to talk with domain experts. Other architectural patterns (e.g. pipes and filters, actors) use terms and concepts that may be harder to grasp by non-programmers.
• Limits the use of ORM (if you use one), I feel ORM's bring in unwarranted complexity if you try and use them for querying, the abstractions are leaky and heavy, trying to tune them is a nightmare :). Using an ORM only on the command side makes things much easier, plain old SQL is the best for queries, probably using a simple library to convert result sets into DTO's is the most you need.

More on how CQRS benefits design can be found here

Also do not forget about the non tangible benefits of CQRS

If you still have your doubts, you may want to read this

We currently use CQRS for projects with medium complexity and have found it be very suitable. We started out using a custom bootstrap code and have now moved on to using the Axon Framework to give us some of the infrastructure components

Feel free to PM me in case you want to know anything more specific.

Secondguess

Answer 3

There is a fundamental problem of Event Sourcing pattern, that is the events in the Event Store may not be compatible with your event handlers in your application any more due to code change.

That being said, whenever you modify the event handler by adding new features, you need to think about the backward compatibility. You have to make sure your code can always handle the same event in different stage created by different version of your code.

When your application becomes more complex, you will find it really pain in the ass to make it backward compatible.

Fitted

Isn't it possible to write migration code from one event storage to another? So you can process the old events and create a very new sequence with the new events... I guess keeping events as small as possible can at least partially prevent this kind of issues. – Vesuvius

@Vesuvius Depends on your domain, it may grow to some complicated scenarios. And the migration code will run every time even there is nothing to migrate. So there is a cost to maintain your code and remove the unused logic from your code. – Fitted

Late comment: This problem exists in all software models of any complexity, not just event sourcing. I believe that the event-sourcing method of explicitly having upgraders on the event stream deals with the problem in a sufficiently formal manner as to make it no more of a hassle than any other architecture – Grower

Answer 4

I think Event Sourcing is what makes people to be afraid of CQRS. And thats for a reason. Its not natural - when you interact with something in real world you don't need to get whole history about this object.

“event sourcing is a completely orthogonal concept to CQRS” (source) - technically if you don't use ES you loose nothing from CQRS features.

I have no idea why Event Sourcing is considered as the only foundation for solving of some "messaging" related problems like: duplication/missing of messages, reordering of messages and data collisions, etc. Its not true that if you don't use Event Sourcing you cant create encapsulated means to solve such problems other way.

How i see alternative ways to implement CQRS's messaging using another data-organizing principle you can read here.

I propose "signed documents" approach where you treat your data not as composition of modification events, but as composition of immutable parts signed by responsible users. Im sure there can be a lot of other solutions to implement message flow and data storage. And you need to take your business model into account when selecting which one you like to use.

Danseuse

Your analogy is wrong. To interact with an existing object that isn't already in memory the computer first has to create that object and restore its state -- in the RL (real life) the object just exists. To restore the object's state the computer can read the stored state from a repository of some kind, or it can recreate it by replaying all the events that have happened to that object since it was created. In RL to re/create an object (maybe replace a broken chair with a new one) you have to replay all the events necessary to create that chair. So, RL is closer to event sourcing. – Grower

@EngineerDollery So You know how exactly your chair was built, every event? And may be whole history of wood it which it was made of? And may be people who made it also affected the process because it's RL. So we have to know their history as well to interact with our chair. The analogy was that we don't have to obtain that history to interact in RL. – Danseuse

the type of wood == the data type of the object components being reconstructed, the people who made it == the methods that were run in order. With event-sourcing we know all that. Like I said, your analogy was wrong -- you're not comparing like with like; you're not just interacting, you're recreating from scratch. In RL if you want to sit on a chair, but it has been destroyed, then you'd have to make one first -- that's event sourcing. – Grower

@EngineerDollery it's up to you to decide what kind of depth you need to make 'new clean chair'. If you need wood and worker methods to create it - it's ok. I go to IKEA and just buy it. For me chair just appears as chair with some properties. I don't know how it was made. Anyway your point is good one. – Danseuse

Answer 5

The best CQRS pattern based framework in my opinion is MediatR by Jimmy Bogard, If you don't need Event Sourcing in the beginning of your application development, MediatR is the right choice. Here is the repository- https://github.com/jbogard/MediatR

Troth

Answer 6

In my opinion, you're making a big mistake by not using event sourcing with CQRS.

First up, you'll almost certainly have issues synchronising your Query model with the Command model. With an event store, if the query side ever gets out of synch, you simply need to replay your events to correct it. That's the theory anyway!

But with Event Sourcing, you also get to store the complete history of all entity transactions. And this means you can decide to create new queries and views after implementation. These are very often views that would not be possible with non-Event Sourced CQRS. I've heard Greg Young give the example of querying items that have been added, and then removed, from a shopping cart. With Event Sourcing this is possible. Without ES it's not possible because you only store the final state of the cart.

China

The ability to create a new view based on the events that occurred is insanely valuable. – Poff

Do you feel that Event-Sourcing can be added over time? Rolled out in phases according to priorities? – Moureaux

Event Sourcing is by no means a prerquisite to the ability to store, review and replay state transitions. Just storing your events in a log table alongside your relational data will give you all you need. See my answer for details. – Trimurti

I think my comment on why NOT using Event Sourcing would be a mistake comes from the perspective of whether you want normalised views on the Query side. I agree that CQRS represents nothing more than a segregation of Commands and Queries (and nothing more). However, if you're looking for increased scalability and performance on your queries, then a dedicated View for each query would be one of the goals. However, if you're adopting CQRS just because you want to separate Commands & Queries, then you have to ask why you are doing this? Scalability? Performance? If so, do correct from the start. – China

I'm using CQS for code maintainability (?) purpose because it's far closer to the business than an OLD CRUD model. And with this model I can easily change my code to increase its performance (eg : instead of views use a separate database system). – Puffy

@Tony Yes, by all means, get "sh1t" done and get stuck in that infinite loop of rewriting everything every 5 years because you can't evolve past CRUD... Stating that DDD et al. are impratical in the real world, makes me question what world it is you are living in, because I can see it working perfectly fine right here in front of me. – Topping

@StefanBilliet Obviously you missed the point. Most developers come from a romantic ideal software dreamland and venture themselves into techniques and philosophies they don't even know about just because of EGO and they don't measure the real BUSINESS implications of delayed projects just because they want to BRAG about their latest piece of code. I'd rather have a CRUD bringing in $700k revenue ($500 profit) than a beautiful perfect DDD software that brings losses to the table just because it has been in "development" for the last 3 years. What World are you living in my friend? – Regin

@Tony In a world where developers are far more professional than you describe, I'm afraid. – Topping

@StefanBilliet Going CRUD or DDD has nothing to do with being professional. Being professional means to deliver results either to investors or the company that pays you a salary. I've encouraged all my developers to pursuit their excellence in programming without losing track of their goals. DDD, CRUD, MACHU PICHU, whatever they feel can be proactive to the project, I will always welcome. But I can't afford having a "kid" experimenting "new" techniques on a team project. You learn in your free time, not on other people's time (money). THAT is being professional to me. Do we agree? – Regin

@Tony I was alluding to your rant about egodriven, goldplating developers. And no, we do not agree. A company is a place of learning and experimenting; the revenue you speak so highly of is a consequence of that learning and experimenting. When talking about a mature development team, the more you step back and let them tackle the problem whichever way they deem best, the greater your succes will be. The more you rant, degrade and distrust, the worse it will be. But you will never believe this and SO is not a suitable place to try and convince you, so I will leave it at this. Good evening. – Topping