4 ms·

I'm currently writing a book about CQRS/ES I'd be glad of your notes about it's downsides.

2017Dude 9y ago
Pragmatic handover of released code and DB to a less technical CRUD team. Avoiding unproven non-anecdotically solutions like EventStore yet still shipping quickly. Avoiding becoming an F#/Scala snob or a JavaScript monkey.
- vorotato 9y ago
  Well it's pretty proven, it's just also likely overkill for what you need. Use it in your personal hobby projects so that you know the costs, and benefits. That way you don't blindly apply it where it doesn't fit (which admittedly will be most places).
arkh 9y ago
Workflows for which some steps depends on things: the current real state of an entity, the permissions the current user has etc. In a client-server system like a web API where you want to respond to the client as fast as possible having to reconstruct your entity from snapshot + some history can take some time. So you end-up with corrective events and responses which are "we have noted your request, poll us to know the result when it's done". The worst is the ES system is already in use in your RDBMS if you use one. Most CQRS + ES demonstration are done with the simple happy path. Rarely something like user A changes the role of user B. User B was saving changes on a document they can't access anymore: what happen? Now with software on your PC or with a constant link to the server things feel a lot more useful.
- partisan 9y ago
  On the CQRS+ES project I worked on for two years, we were just thinking about the happy path at first before realizing that was a mistake. For your example, here are two approaches depending on your implementation and your tolerance for edge cases and eventual consistency: - you can enter into a saga which would do a two phase commit, ensuring that the user is indeed authorized when the edit is made. All possible states are captured in your event model and so your event history will always show what has happened - you can load the document aggregate when you process the command and query it at that time, throwing an exception if the user is not authorized and then you can notify the user or send another command. In this case, your event model does not have to include events that describe the violation of domain rules The first option gives you the guarantee you are looking for, but comes at the cost of complexity. The second option will give you the correct results unless a user is deauthorized before the edit command completes. Some systems process all commands in serial and so it would not be a problem. Some systems partition their commands to distribute the work and so this edge case can occur. But you can select what makes most sense for you.
  - naasking 9y ago
    > Some systems partition their commands to distribute the work and so this edge case can occur. So basically don't introduce race conditions that aren't inherently part of the domain. This seems like a modelling failure to me.
k__ 9y ago
I think many people just dislike DDD and CQRS/ES because it's associated with over engineering. Either you are really good and get things right without much help, which isn't often the case, or you end up in two other directions. You over-engineer with DDD/CQRS/ES. You under-engineer without them. Most developers I met preferred the last solution, probably because they end up with their "own" mess and not the mess of some process. And I have to admit, the only people I met, that used these techniques, were some "digital transformation" consultants who made their living by selling this stuff to big corps, which isn't too convincing either.
- ptr 9y ago
  For some projects, ES isn't over-engineering. It can be useful when writing to a database is too slow, for example.
- naasking 9y ago
  > You over-engineer with DDD/CQRS/ES. CQRS/ES definitely seems like a correct foundations for a distributed system, I just don't think we have the right abstractions to properly model this without wanting to stab yourself in the eye.

2017Dude 9y ago

Pragmatic handover of released code and DB to a less technical CRUD team. Avoiding unproven non-anecdotically solutions like EventStore yet still shipping quickly. Avoiding becoming an F#/Scala snob or a JavaScript monkey.

vorotato 9y ago
Well it's pretty proven, it's just also likely overkill for what you need. Use it in your personal hobby projects so that you know the costs, and benefits. That way you don't blindly apply it where it doesn't fit (which admittedly will be most places).

arkh 9y ago

Workflows for which some steps depends on things: the current real state of an entity, the permissions the current user has etc. In a client-server system like a web API where you want to respond to the client as fast as possible having to reconstruct your entity from snapshot + some history can take some time. So you end-up with corrective events and responses which are "we have noted your request, poll us to know the result when it's done". The worst is the ES system is already in use in your RDBMS if you use one. Most CQRS + ES demonstration are done with the simple happy path. Rarely something like user A changes the role of user B. User B was saving changes on a document they can't access anymore: what happen? Now with software on your PC or with a constant link to the server things feel a lot more useful.

partisan 9y ago
On the CQRS+ES project I worked on for two years, we were just thinking about the happy path at first before realizing that was a mistake. For your example, here are two approaches depending on your implementation and your tolerance for edge cases and eventual consistency: - you can enter into a saga which would do a two phase commit, ensuring that the user is indeed authorized when the edit is made. All possible states are captured in your event model and so your event history will always show what has happened - you can load the document aggregate when you process the command and query it at that time, throwing an exception if the user is not authorized and then you can notify the user or send another command. In this case, your event model does not have to include events that describe the violation of domain rules The first option gives you the guarantee you are looking for, but comes at the cost of complexity. The second option will give you the correct results unless a user is deauthorized before the edit command completes. Some systems process all commands in serial and so it would not be a problem. Some systems partition their commands to distribute the work and so this edge case can occur. But you can select what makes most sense for you.
- naasking 9y ago
  > Some systems partition their commands to distribute the work and so this edge case can occur. So basically don't introduce race conditions that aren't inherently part of the domain. This seems like a modelling failure to me.

k__ 9y ago

I think many people just dislike DDD and CQRS/ES because it's associated with over engineering. Either you are really good and get things right without much help, which isn't often the case, or you end up in two other directions. You over-engineer with DDD/CQRS/ES. You under-engineer without them. Most developers I met preferred the last solution, probably because they end up with their "own" mess and not the mess of some process. And I have to admit, the only people I met, that used these techniques, were some "digital transformation" consultants who made their living by selling this stuff to big corps, which isn't too convincing either.

ptr 9y ago
For some projects, ES isn't over-engineering. It can be useful when writing to a database is too slow, for example.
naasking 9y ago
> You over-engineer with DDD/CQRS/ES. CQRS/ES definitely seems like a correct foundations for a distributed system, I just don't think we have the right abstractions to properly model this without wanting to stab yourself in the eye.