9 ms·

Show HN: Learn what DDD, CQRS, and event-sourcing are all about

138 points by goloroden 9y ago

gspetr 9y ago
I apologize for making a meta comment, but I had to modify the way the article is displayed because it's an all too common example of this: https://www.wired.com/2016/10/how-the-web-became-unreadable/ https://www.wired.com/2016/10/how-the-web-became-unreadable/ Which is very annoying because the article about CSS can't get it's UI right. They call Svelte "The magical disappearing UI framework" and indeed, their fonts look like they are written in an invisble ink about to dry up.
Yuioup 9y ago
Run away. Run far, far away from CQRS and Event Sourcing.
- akoenig 9y ago
  Hö? Why is that? Can you elaborate a little bit on that?
- codebeaker 9y ago
  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.
- Beltiras 9y ago
  This is the sort of comments that get downvoted usually. You make a blanket statement backing it up with exactly zero characters of evidence or even academic theory. I found thinking in those terms helped me find architecture for webapps that made sense and was extendable and robust. Can you elaborate on why one should stay away?
- mtarnovan 9y ago
  This comment isn't very helpful. Still, it should be noted that Fowler warns that CRQS adds significant complexity and advises great caution about using it. See https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html
  - bottlenecked 9y ago
    Greg Young also cautions "Do not tell me you've built an event sourced system"* (or something along those lines) meaning that you should be careful to apply the pattern only to the part(s) of the system that makes sense (due to the increased complexity of ES) * I think it's in this talk https://www.youtube.com/watch?v=JHGkaShoyNs https://www.youtube.com/watch?v=JHGkaShoyNs
- cessor 9y ago
  Could you elaborate?
goloroden 9y ago
Hey :-) I'm one of the authors of wolkenkit, so if you have any questions, feel free to ask here :-)
- codebeaker 9y ago
  As a non-native German speaker who's lived in Germany for coming up on 10 years, aren't you concerned that it'll be pronounced like "wol-kenkit" not "volkenkit" for non-germans? Naming things is hard but after watching UBER Inc destroy the pronunciation, spelling and etc of a German word, I'm always cautious about unusual names. (Also because, as now I'm hung up on the name before giving your product a fair chance)
  - goloroden 9y ago
    Well, yes, there's a certain risk. We had the idea that people liked the word "wolke" (German for "cloud"). Anyway, of course, I would be very happy if you gave wolkenkit a second chance ;-)
    - codebeaker 9y ago
      I did - reading the brochure now, the word "semantic" keeps cropping up and I wonder if it's an unsympathetic translation from German, or I'm too far away from the JS world to understand that "Semantic" means: > That‘s why we have built wolkenkit, a semantic JavaScript backend that addresses three important aspects of software development, and that empowers you to build better software faster. There's a bunch of things wrong with this claim, "a javascript backend" sounds like an alternative JS VM to me, a backend for javascript (I presume it's meant that this is server side JS not client side?) I also always get my back up when I read "build software faster", surely it ought to be about maintainability when it comes to the perks of DDD/CQRS.
      - goloroden 9y ago
        Actually, you're right. What we mean is that it's a backend for JavaScript applications, which itself uses JavaScript.
perlgeek 9y ago
There is a disconnect in your messaging. Here on HN the title is "Learn what DDD, CQRS, and event-sourcing are all about", but the tagline in the PDF is "The semantic JavaScript backend for event-driven development". So, what's this about? about DDD, CQRS and event-sourcing, or about a particular Javascript framework? Those two aren't the same at all (even though I suspect there is a little overlap).
- goloroden 9y ago
  The brochure is to 2/3s an introduction to DDD, CQRS, and event-sourcing in general, not being related to a specific JavaScript framework. The last 1/3 shows how to apply these concepts using wolkenkit, which is a specific framework. When we created the brochure it seemed important to us to first explain the concepts in a neutral way, because we want to help people gain a better understanding of these concepts, no matter whether they are going to use wolkenkit or not.
  - perlgeek 9y ago
    That's great. My point is that the title page does not properly represent that. You might have an easier time getting people to read it when they don't get the impression "it's just another javascript framework".
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.
EdSharkey 9y ago
Reshaping data is the source of so many costly bugs and communications breakdowns in this world. CQRS is like descending to the 8th circle, pit 7 of reshaping hell. What fetish drives one to such tortures? If your schema is any more complicated than a plain stream of characters, and you pick CQRS for your app, then you are an overpaid, bored, architecture astronaut consultant looking to pad his resume. Nevermind the multi-million dollar dumpster fire of an app you spearheaded and ditched out on before completing (and that got cancelled, of course, a complete loss.) If I ever saw CQRS on a resume, I'd unconditionally pass, you're not setting foot in the door.
- UK-AL 9y ago
  CQRS just simply means your queries, and commands have separate paths. This can be as simple or as complicated as someone wants to make it. It could be as simple as having commands operate on a domain object, but the queries returning a fully populated view object from some custom sql.
  - EdSharkey 9y ago
    Are those objects in the queries and queues separate and distinct types then? And, what about the object store, what types go in there? How do we handle data migrations? I like queues as much as the next developer. Queues let you scale performance Mt Everest and deal with concurrency. CQRS as an architecture is like queue abuse.
    - UK-AL 9y ago
      You don't have to use queues, separate objects/NoSQL store or anything like that to use cqrs. I mean you can use them, but all CQRS means is a separate code path for queries and commands. In my system I have command objects, they operate on domain objects which contain some business logic. I have query objects which just execute custom sql code which returns a populated view. This is useful because views often display specific data from multiple domain objects. This system allows you to bring back the entire view in a single query and nothing else, rather trying to retrieve multiple domain objects which are really designed for business rules rather than queries. Often yes, people do starting adding queues, materialised views to CQRS which can make it complicated.
aaronmu 9y ago
Can anyone explain why eventual consistency is so scary? The way I see it, eventual consistency is everywhere. Even in your non-distributed synchronous CRUD app. The minute you start two db transactions within one script you have eventual consistency. You have to deal with the fact that one transaction can fail and that your state can be inconsistent.
- jorgeleo 9y ago
  It really depends on the application. Eventual consistency means that eventually, the databases will be consistent. Some bank transactions, for example, do not have that luxury because it might allow 2 possible answers to the same query if the eventuality has not been met. Some trading transactions don't have that luxury either because the milliseconds that you waited for the consistency a stock might have changed its price dramatically. It really depends on the Domain if the time to wait for the eventuality is acceptable or not.
  - gregyoung1 9y ago
    Bank transactions are eventually consistent. How do you think you can get an overdraft fee? Ever use a gas pump and notice it took a $1 authorization on your card then later settled for what you pumped? Eventual consistency is not all that scary, try putting on a business hat instead of a technical one. Its about risk management.
  - nightski 9y ago
    Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios. Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy.
    - jorgeleo 9y ago
      "Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios." I live in the US, and if I got to the ATM and get cash on my account, I can go to my iPhone app and see the transaction and the balance updated. Yes, there is a nightly process, but not everything is a nightly process. "Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy." Do you know what a hedge fund is?
victorNicollet 9y ago
The DDD/CQRS/ES topic appears on Hacker News every so often, and never fails to stir a strong debate. In fact, I was going to "Show HN" an Event Sourcing library I open sourced yesterday, but I guess I'll wait until everything dies down a bit :-) I believe that the core principles of DDD/CQRS/ES are flawed and are the cause of a lot of pain. If your team plows forward and ignores the pain, you will have a bad experience working there. If your team decides to fix the problems with the architecture (usually in a way that's rather specific to their situation), and still insists that they're doing DDD/CQRS/ES, then you will have a great experience. The same can be said of many approaches to SQL database design. When I joined Lokad, most of the code had been written by a strong CQRS advocate, and there were significant pain points caused by this approach that would have been nonexistent with a plain old SQL architecture. The author himself did a retrospective that covers a few issues: https://abdullin.com/lokad-cqrs-retrospective/ https://abdullin.com/lokad-cqrs-retrospective/ Instead of dropping everything and moving back to a more conventional SQL architecture, we dropped everything and moved to a solution which, if I were to describe it as DDD/CQRS/ES, would have me branded as a heretic by the DDD/CQRS/ES community: it does fit the definition, but it does not follow the best practices. There is a single data model shared by both commands and queries. Commands can sometimes return data. Each (micro?)service has access to exactly one aggregate. There is no uncertainty on event ordering, and no eventual consistency at the aggregate level. Materialized views for each aggregate are kept in-memory at all times. All of these intentional weakenings of the CQRS architecture were driven by pragmatic needs, and made with knowledge of the consequences.
- bonesss 9y ago
  > The author himself did a retrospective that covers a few issues: https://abdullin.com/lokad-cqrs-retrospective/ https://abdullin.com/lokad-cqrs-retrospective/ Having read the article: veeeeeery little of what is mentioned is related in any meaningful sense to CQRS... Horse-before-the-cart framework design is always bad. Encapsulating untested theories in frameworks instead of lifting them from operational designs, always bad. Building frameworks as a learning exercise, bad. Abstracting away data decisions and then trying to provide opinionated answers to storage at the framework level, very bad. Conflating logical system architecture with supplier provided products (ie cloud services), is framework _cancer_. That is simply not a reasonable starting point to provide value and scalable systems, and the end result was the same as all other similar attempts: an A for effort with a result that was at best 'close, but not quite...' To be clear: I do not intend this as criticism leveled at the author or the company. The article is great. I very much agree with his analysis though: > Lokad.CQRS was created with a very short-sighted design approach in mind, a reusable LEGO constructor...These days I'd try to limit the damage I inflict upon the developers and avoid writing any widely reusable frameworks This is where all the issues lay... Premature framework development causing up-front decisions untethered to practicality based on conjecture and prognostication instead of experience in a challenging domain insufficiently understood by the framework architect. From a high level perspective: neither CQRS, nor framework development, nor application development were sufficiently groked before being baked into a long-term production commitment. Those are organizational issues, not CQRS issues. In the same vein, coming from such an environment and basing judgment of DDD or CQRS on anything that came from that environment won't hold water. The architectural problems you're talking about, the core principles you think are flawed, work stunningly well in other places that have not made the same underlying mistakes. CQRS advocates != CQRS experts != framework experts.
bauerd 9y ago
Offtopic, but was the PDF typeset with layouting software or a markup converter such as Pandoc and the like? Looks really slick, kudos. Also is there a way to tell by PDF metadata? Edit: Had a second look and it's layouting software
shock 9y ago
> In fact, not even credit institutes work with transactions, they too rely on eventually being consistent. Is this really the case? I was always under the impression that everything regarding financial transactions needed to be transactional.
- andreareina 9y ago
  Consistency here is CAP consistency[1], not ACID consistency. In short, if datum d is visible to Alice at time t1, it MUST also be visible to Bob at time t2 > t1. So financial transactions are transactional, but there's no guarantee that every node has a fully up-to-date state at all times. [1]: https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem
  - jen20 9y ago
    This is also not how bank transfers work inter-bank. I as Bob (a recipient) may have zero knowledge of a transaction initiated by Alice regardless of time.
- jen20 9y ago
  Wrong. Do you seriously think that a cross-bank transfer is operating inside a distributed database transaction? Furthermore, what did banks do before they had computer systems available?
- gregyoung1 9y ago
  Bank transactions are usually handled via long running messaging state machines. When as example you transfer from an account in the US to one in Sweden it does not just open a 2PC transaction between the two databases. There are also often intermediaries involved.
- jamesb7276 9y ago
  write a check
raarts 9y ago
Reading this.... It's just like react and redux, combined with redux-sagas. My head is spinning.
- gregyoung1 9y ago
  Only made 10 years prior.

138 points by goloroden 9y ago

I apologize for making a meta comment, but I had to modify the way the article is displayed because it's an all too common example of this: https://www.wired.com/2016/10/how-the-web-became-unreadable/ https://www.wired.com/2016/10/how-the-web-became-unreadable/ Which is very annoying because the article about CSS can't get it's UI right. They call Svelte "The magical disappearing UI framework" and indeed, their fonts look like they are written in an invisble ink about to dry up.

Yuioup 9y ago

Run away. Run far, far away from CQRS and Event Sourcing.

akoenig 9y ago
Hö? Why is that? Can you elaborate a little bit on that?
codebeaker 9y ago
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.
Beltiras 9y ago
This is the sort of comments that get downvoted usually. You make a blanket statement backing it up with exactly zero characters of evidence or even academic theory. I found thinking in those terms helped me find architecture for webapps that made sense and was extendable and robust. Can you elaborate on why one should stay away?
mtarnovan 9y ago
This comment isn't very helpful. Still, it should be noted that Fowler warns that CRQS adds significant complexity and advises great caution about using it. See https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html
- bottlenecked 9y ago
  Greg Young also cautions "Do not tell me you've built an event sourced system"* (or something along those lines) meaning that you should be careful to apply the pattern only to the part(s) of the system that makes sense (due to the increased complexity of ES) * I think it's in this talk https://www.youtube.com/watch?v=JHGkaShoyNs https://www.youtube.com/watch?v=JHGkaShoyNs
cessor 9y ago
Could you elaborate?

goloroden 9y ago

Hey :-) I'm one of the authors of wolkenkit, so if you have any questions, feel free to ask here :-)

codebeaker 9y ago
As a non-native German speaker who's lived in Germany for coming up on 10 years, aren't you concerned that it'll be pronounced like "wol-kenkit" not "volkenkit" for non-germans? Naming things is hard but after watching UBER Inc destroy the pronunciation, spelling and etc of a German word, I'm always cautious about unusual names. (Also because, as now I'm hung up on the name before giving your product a fair chance)
- goloroden 9y ago
  Well, yes, there's a certain risk. We had the idea that people liked the word "wolke" (German for "cloud"). Anyway, of course, I would be very happy if you gave wolkenkit a second chance ;-)
  - codebeaker 9y ago
    I did - reading the brochure now, the word "semantic" keeps cropping up and I wonder if it's an unsympathetic translation from German, or I'm too far away from the JS world to understand that "Semantic" means: > That‘s why we have built wolkenkit, a semantic JavaScript backend that addresses three important aspects of software development, and that empowers you to build better software faster. There's a bunch of things wrong with this claim, "a javascript backend" sounds like an alternative JS VM to me, a backend for javascript (I presume it's meant that this is server side JS not client side?) I also always get my back up when I read "build software faster", surely it ought to be about maintainability when it comes to the perks of DDD/CQRS.
    - goloroden 9y ago
      Actually, you're right. What we mean is that it's a backend for JavaScript applications, which itself uses JavaScript.

perlgeek 9y ago

There is a disconnect in your messaging. Here on HN the title is "Learn what DDD, CQRS, and event-sourcing are all about", but the tagline in the PDF is "The semantic JavaScript backend for event-driven development". So, what's this about? about DDD, CQRS and event-sourcing, or about a particular Javascript framework? Those two aren't the same at all (even though I suspect there is a little overlap).

goloroden 9y ago
The brochure is to 2/3s an introduction to DDD, CQRS, and event-sourcing in general, not being related to a specific JavaScript framework. The last 1/3 shows how to apply these concepts using wolkenkit, which is a specific framework. When we created the brochure it seemed important to us to first explain the concepts in a neutral way, because we want to help people gain a better understanding of these concepts, no matter whether they are going to use wolkenkit or not.
- perlgeek 9y ago
  That's great. My point is that the title page does not properly represent that. You might have an easier time getting people to read it when they don't get the impression "it's just another javascript framework".

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.

EdSharkey 9y ago

Reshaping data is the source of so many costly bugs and communications breakdowns in this world. CQRS is like descending to the 8th circle, pit 7 of reshaping hell. What fetish drives one to such tortures? If your schema is any more complicated than a plain stream of characters, and you pick CQRS for your app, then you are an overpaid, bored, architecture astronaut consultant looking to pad his resume. Nevermind the multi-million dollar dumpster fire of an app you spearheaded and ditched out on before completing (and that got cancelled, of course, a complete loss.) If I ever saw CQRS on a resume, I'd unconditionally pass, you're not setting foot in the door.

UK-AL 9y ago
CQRS just simply means your queries, and commands have separate paths. This can be as simple or as complicated as someone wants to make it. It could be as simple as having commands operate on a domain object, but the queries returning a fully populated view object from some custom sql.
- EdSharkey 9y ago
  Are those objects in the queries and queues separate and distinct types then? And, what about the object store, what types go in there? How do we handle data migrations? I like queues as much as the next developer. Queues let you scale performance Mt Everest and deal with concurrency. CQRS as an architecture is like queue abuse.
  - UK-AL 9y ago
    You don't have to use queues, separate objects/NoSQL store or anything like that to use cqrs. I mean you can use them, but all CQRS means is a separate code path for queries and commands. In my system I have command objects, they operate on domain objects which contain some business logic. I have query objects which just execute custom sql code which returns a populated view. This is useful because views often display specific data from multiple domain objects. This system allows you to bring back the entire view in a single query and nothing else, rather trying to retrieve multiple domain objects which are really designed for business rules rather than queries. Often yes, people do starting adding queues, materialised views to CQRS which can make it complicated.

aaronmu 9y ago

Can anyone explain why eventual consistency is so scary? The way I see it, eventual consistency is everywhere. Even in your non-distributed synchronous CRUD app. The minute you start two db transactions within one script you have eventual consistency. You have to deal with the fact that one transaction can fail and that your state can be inconsistent.

jorgeleo 9y ago
It really depends on the application. Eventual consistency means that eventually, the databases will be consistent. Some bank transactions, for example, do not have that luxury because it might allow 2 possible answers to the same query if the eventuality has not been met. Some trading transactions don't have that luxury either because the milliseconds that you waited for the consistency a stock might have changed its price dramatically. It really depends on the Domain if the time to wait for the eventuality is acceptable or not.
- gregyoung1 9y ago
  Bank transactions are eventually consistent. How do you think you can get an overdraft fee? Ever use a gas pump and notice it took a $1 authorization on your card then later settled for what you pumped? Eventual consistency is not all that scary, try putting on a business hat instead of a technical one. Its about risk management.
- nightski 9y ago
  Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios. Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy.
  - jorgeleo 9y ago
    "Banks have daily lag (pending transactions). They also stop business in the evening and resume in the morning to process all these items. That isn't feasible in a lot of scenarios." I live in the US, and if I got to the ATM and get cash on my account, I can go to my iPhone app and see the transaction and the balance updated. Yes, there is a nightly process, but not everything is a nightly process. "Rarely do you have an up to the microsecond view of the markets (unless you are located appropriately and pay significant amounts of money). There is always a delay in the information's accuracy and relevancy." Do you know what a hedge fund is?

victorNicollet 9y ago

The DDD/CQRS/ES topic appears on Hacker News every so often, and never fails to stir a strong debate. In fact, I was going to "Show HN" an Event Sourcing library I open sourced yesterday, but I guess I'll wait until everything dies down a bit :-) I believe that the core principles of DDD/CQRS/ES are flawed and are the cause of a lot of pain. If your team plows forward and ignores the pain, you will have a bad experience working there. If your team decides to fix the problems with the architecture (usually in a way that's rather specific to their situation), and still insists that they're doing DDD/CQRS/ES, then you will have a great experience. The same can be said of many approaches to SQL database design. When I joined Lokad, most of the code had been written by a strong CQRS advocate, and there were significant pain points caused by this approach that would have been nonexistent with a plain old SQL architecture. The author himself did a retrospective that covers a few issues: https://abdullin.com/lokad-cqrs-retrospective/ https://abdullin.com/lokad-cqrs-retrospective/ Instead of dropping everything and moving back to a more conventional SQL architecture, we dropped everything and moved to a solution which, if I were to describe it as DDD/CQRS/ES, would have me branded as a heretic by the DDD/CQRS/ES community: it does fit the definition, but it does not follow the best practices. There is a single data model shared by both commands and queries. Commands can sometimes return data. Each (micro?)service has access to exactly one aggregate. There is no uncertainty on event ordering, and no eventual consistency at the aggregate level. Materialized views for each aggregate are kept in-memory at all times. All of these intentional weakenings of the CQRS architecture were driven by pragmatic needs, and made with knowledge of the consequences.

bonesss 9y ago
> The author himself did a retrospective that covers a few issues: https://abdullin.com/lokad-cqrs-retrospective/ https://abdullin.com/lokad-cqrs-retrospective/ Having read the article: veeeeeery little of what is mentioned is related in any meaningful sense to CQRS... Horse-before-the-cart framework design is always bad. Encapsulating untested theories in frameworks instead of lifting them from operational designs, always bad. Building frameworks as a learning exercise, bad. Abstracting away data decisions and then trying to provide opinionated answers to storage at the framework level, very bad. Conflating logical system architecture with supplier provided products (ie cloud services), is framework _cancer_. That is simply not a reasonable starting point to provide value and scalable systems, and the end result was the same as all other similar attempts: an A for effort with a result that was at best 'close, but not quite...' To be clear: I do not intend this as criticism leveled at the author or the company. The article is great. I very much agree with his analysis though: > Lokad.CQRS was created with a very short-sighted design approach in mind, a reusable LEGO constructor...These days I'd try to limit the damage I inflict upon the developers and avoid writing any widely reusable frameworks This is where all the issues lay... Premature framework development causing up-front decisions untethered to practicality based on conjecture and prognostication instead of experience in a challenging domain insufficiently understood by the framework architect. From a high level perspective: neither CQRS, nor framework development, nor application development were sufficiently groked before being baked into a long-term production commitment. Those are organizational issues, not CQRS issues. In the same vein, coming from such an environment and basing judgment of DDD or CQRS on anything that came from that environment won't hold water. The architectural problems you're talking about, the core principles you think are flawed, work stunningly well in other places that have not made the same underlying mistakes. CQRS advocates != CQRS experts != framework experts.

bauerd 9y ago

Offtopic, but was the PDF typeset with layouting software or a markup converter such as Pandoc and the like? Looks really slick, kudos. Also is there a way to tell by PDF metadata? Edit: Had a second look and it's layouting software

shock 9y ago

> In fact, not even credit institutes work with transactions, they too rely on eventually being consistent. Is this really the case? I was always under the impression that everything regarding financial transactions needed to be transactional.

andreareina 9y ago
Consistency here is CAP consistency[1], not ACID consistency. In short, if datum d is visible to Alice at time t1, it MUST also be visible to Bob at time t2 > t1. So financial transactions are transactional, but there's no guarantee that every node has a fully up-to-date state at all times. [1]: https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem
- jen20 9y ago
  This is also not how bank transfers work inter-bank. I as Bob (a recipient) may have zero knowledge of a transaction initiated by Alice regardless of time.
jen20 9y ago
Wrong. Do you seriously think that a cross-bank transfer is operating inside a distributed database transaction? Furthermore, what did banks do before they had computer systems available?
gregyoung1 9y ago
Bank transactions are usually handled via long running messaging state machines. When as example you transfer from an account in the US to one in Sweden it does not just open a 2PC transaction between the two databases. There are also often intermediaries involved.
jamesb7276 9y ago
write a check

raarts 9y ago

Reading this.... It's just like react and redux, combined with redux-sagas. My head is spinning.

gregyoung1 9y ago
Only made 10 years prior.