3 ms·

While event sourcing is a quite alright tech for certain problems, this idea of "one solution fits all" is just ridiculous. Also the idea of "eventual consisten

by he0001 9y ago

While event sourcing is a quite alright tech for certain problems, this idea of "one solution fits all" is just ridiculous. Also the idea of "eventual consistency" is highly situational particularly in an distributed solution. Paradoxically looking at one event source log this looks like a great idea, but there are no guarantees that events propagate evenly and "in-order" so even if events happen and there's "nothing you can do about it", systems will still be out of order, when read in relation to each other because the systems won't know that any other event actually have happened. The system will happily consume it because it won't have the proper info or acted on the wrong information. No matter how you try to mitigate this this will happen and you won't have the slightest idea that it happened. Worst of all, you can't recover from it because the information is gone. It's just fundamental aspect of asynchronous programming, conveniently forgotten trying to sell solutions.

josephg 9y ago
This is a problem in how lots of people do event sourcing, but its not a fundamental problem with event sourcing. If you enforce strict ordering of events throughout your stack and do operation catchup properly, these sorts of bugs are completely avoidable.
- he0001 9y ago
  Well that's the entire problem, you are not the one making the requirements, the solution of the problem does... You can't eat dinner before you have made it. Edit: I would argue that you can't write a system which is open (several domains) and believe that you will have entirely independent events throughout the system and claim that your system will be "bugfree"/correct.
  - nightski 9y ago
    I could be missing something but I feel like you are inventing an impossible scenario. You may not be making the requirements, but the requirements have to be technically feasible. CQRS/DDD give you a lot of flexibility on where to choose your boundaries/aggregate roots and these are designed around the business/requirements. If you can give a valid scenario where this model breaks down but others would succeed I'd be very interested.
    - he0001 9y ago
      It's not requirements by "what to do" but the requirements of "what we need to make "what to do"" work. For example if you are going to add two numbers you have to use some sort of arithmetic to solve that problem, right? If you fail using arithmetic to solve it you will not solve the problem and your function will do something else. The requirement of solving in this particular case will be "use arithmetic". So this means for your problem to be correct you have to use the correct tools to solve that problem. If you think that everything (all problems) can be decomposed to independent events, which per definition can happen in any order, you can safely use ES. But if they have any dependency on each other you need ordering, and ordering in a distributed system is a hard problem. And add to this is that somewhere some guy from the business will come up with an actual requirement where you must synchronize and if you then have solution which inherently where this is not possible you are screwed. This is true for both reading and writing in that system. Most problems are dependent otherwise it won't solve/do anything, there are usually a purpose with most systems. While you can have systems where the events are entirely independent, structurally independent, such as JS event loop and red/blue methods (just locally independent), or it doesn't matter like plain application logs, this is rarely, if not impossible between domains if you want a correct system since you won't know if all events have arrived yet to tigger another event, if there's any dependency between them, which there will be between two domains. DDD is good but not in this context, CQRS is trying to partially to solve above problems, but not needed and is just bloating. It does fit better with C# since the (weird) implementation of async/await and potentially with JS for the same reasons. ES do have their use cases where they fit very well but not with the practical impacts of DDD.
    - victorNicollet 9y ago
      Here's an example from the Wolkenkit brochure: > user.login({ login: 'user', password: 'secret'}); > const isUserLoggedIn = user.isLoggedIn(); If you look at this purely from an API design point of view, this stinks: by forcing the command to return void, the code ends up twisting its design to return the result of the command through an artificial channel (the state of the 'user' object). In the end, we are still interested in "the result of the login attempt", and the easiest way to do this would be a function that returns a value: > const isUserLoggedIn = user.login({ login: 'user', password: 'secret' });
he0001 9y ago
And by "one solution fits all" I mean CQRS.

by he0001 9y ago

josephg 9y ago

This is a problem in how lots of people do event sourcing, but its not a fundamental problem with event sourcing. If you enforce strict ordering of events throughout your stack and do operation catchup properly, these sorts of bugs are completely avoidable.

he0001 9y ago
Well that's the entire problem, you are not the one making the requirements, the solution of the problem does... You can't eat dinner before you have made it. Edit: I would argue that you can't write a system which is open (several domains) and believe that you will have entirely independent events throughout the system and claim that your system will be "bugfree"/correct.
- nightski 9y ago
  I could be missing something but I feel like you are inventing an impossible scenario. You may not be making the requirements, but the requirements have to be technically feasible. CQRS/DDD give you a lot of flexibility on where to choose your boundaries/aggregate roots and these are designed around the business/requirements. If you can give a valid scenario where this model breaks down but others would succeed I'd be very interested.
  - he0001 9y ago
    It's not requirements by "what to do" but the requirements of "what we need to make "what to do"" work. For example if you are going to add two numbers you have to use some sort of arithmetic to solve that problem, right? If you fail using arithmetic to solve it you will not solve the problem and your function will do something else. The requirement of solving in this particular case will be "use arithmetic". So this means for your problem to be correct you have to use the correct tools to solve that problem. If you think that everything (all problems) can be decomposed to independent events, which per definition can happen in any order, you can safely use ES. But if they have any dependency on each other you need ordering, and ordering in a distributed system is a hard problem. And add to this is that somewhere some guy from the business will come up with an actual requirement where you must synchronize and if you then have solution which inherently where this is not possible you are screwed. This is true for both reading and writing in that system. Most problems are dependent otherwise it won't solve/do anything, there are usually a purpose with most systems. While you can have systems where the events are entirely independent, structurally independent, such as JS event loop and red/blue methods (just locally independent), or it doesn't matter like plain application logs, this is rarely, if not impossible between domains if you want a correct system since you won't know if all events have arrived yet to tigger another event, if there's any dependency between them, which there will be between two domains. DDD is good but not in this context, CQRS is trying to partially to solve above problems, but not needed and is just bloating. It does fit better with C# since the (weird) implementation of async/await and potentially with JS for the same reasons. ES do have their use cases where they fit very well but not with the practical impacts of DDD.
  - victorNicollet 9y ago
    Here's an example from the Wolkenkit brochure: > user.login({ login: 'user', password: 'secret'}); > const isUserLoggedIn = user.isLoggedIn(); If you look at this purely from an API design point of view, this stinks: by forcing the command to return void, the code ends up twisting its design to return the result of the command through an artificial channel (the state of the 'user' object). In the end, we are still interested in "the result of the login attempt", and the easiest way to do this would be a function that returns a value: > const isUserLoggedIn = user.login({ login: 'user', password: 'secret' });

he0001 9y ago

And by "one solution fits all" I mean CQRS.