42 Comments

1. Mark Seemann Says:
   April 22nd, 2011 at 3:08 pm

   Based on the amount of experience I’ve had so far with CQRS (without event sourcing) is that what I really like about it is that it makes complexity explicit.

   The fact that we explicitly choose to reduce all operations with side effects to pure Commands is very beneficial because that means we can use a Pipes and Filter architecture to handle them. Commands are also the most composable form of abstraction: http://blog.ploeh.dk/2011/03/22/CommandsAreComposable.aspx

   That all complexity is handled by autonomous components is, IMO, very attractive because it tends to be very easy to unit test them. Reads are just direct queries, so need almost no testing.

   While I find the scalability promises of CQRS attractive, I really don’t think it’s the key benefit. Complexity management is.



2. Stacy Says:
   April 23rd, 2011 at 4:01 am

   Wow – this is the most shocking article I’ve read here. Almost feels like April Fools day.

   I must say that I find CQRS liberating as hell from that big monolithic domain morass I use for commands AND queries. I never saw it for collaboration concerns because my web apps are just like you said, non-collaborative. Nor do I need snapshots and concurrency checking. So I’m left with something far simpler than what I use to do. Unit testing with events is far simpler than per class, brittle TDD. Throw in codegen, replaying events to get another view, messaging, and I don’t feel the complexity you speak about here. A real-time event log is simply invaluable to a startup, as well as a head start on scaling built right in.

   But I can understand your point about confusion as I learn about this stuff. When I see long complex questions-answers on the cqrs group, most seem to be rooted in poor DDD modeling, IMHO. If you don’t get the bounded contexts and aggregate roots properly identified, it’s just massive confusion and making up new rules to shoe-horn a solution into cqrs-es-read model-ui type pattern.

   Udi I have learned sooooo much from you about cqrs. Thank you! And I do hope you’ll continue to help us figure things out. Sometimes the value unexpectantly falls further from the tree 🙂



3. udidahan Says:
   April 23rd, 2011 at 9:36 am

   Mark,

   I’d say that SOA is the primary way to mitigate complexity (when done right). Often there is so little complexity left after that that CQRS (or any other technique for that matter) is unnecessary.



4. Mark Seemann Says:
   April 23rd, 2011 at 10:57 am

   I know that I need to attend your course (one day I will), but the way you present SOA and the way you present CQRS they seem very closely related to me.

   That wasn’t a criticism – it’s an observation that makes lots of sense to me.



5. Adam D. Says:
   April 23rd, 2011 at 11:40 am

   Multiple models, cqrs or not, within domains, is something that is not used often enough. Complexity arises often from trying to cram too much into one thing to “get the design right”. Cqrs may overshoot what the ideal is, but this is needed at this time of the love-in with the active record pattern. Perhaps this post is a warning to those getting in over their heads too early in their careers.



6. udidahan Says:
   April 23rd, 2011 at 12:32 pm

   Mark,

   While there are similar foundational principles to both SOA and CQRS, their usage is intended for very different circumstances.



7. Colin Jack Says:
   April 23rd, 2011 at 12:32 pm

   “Here’s the strongest indication I can give you to know that you’re doing CQRS correctly: Your aggregate roots are sagas.”

   Not sure I follow, have you written about this elsewhere?



8. udidahan Says:
   April 23rd, 2011 at 12:34 pm

   Adam,

   I don’t think the purpose of CQRS was to pull the industry away from monolithic active-record hell (even if it did that for some). But maybe the devil you know is better than the one you don’t.



9. udidahan Says:
   April 23rd, 2011 at 2:16 pm

   Stacy,

   Sometimes people mistaken the use of the technical elements of CQRS (messaging etc) for CQRS. Also, many try to apply it without the division of bounded contexts (a.k.a SOA services).

   There is no such thing as an unequivocal ubiquitous best practice.



10. udidahan Says:
    April 23rd, 2011 at 2:16 pm

    Colin,

    That was my post on race conditions.



11. Łukasz Podolak Says:
    April 23rd, 2011 at 2:20 pm

    Udi,

    “Therefore, I’m sorry to say that most sample application you’ll see online that show CQRS are architecturally wrong. I’d also be extremely wary of frameworks that guide you towards an entity-style aggregate root CQRS model.”

    Could you be more explicit with this? Which example and which framework should we be wary and why ?



12. John Teague Says:
    April 23rd, 2011 at 8:45 pm

    Udi,
    Could you elaborate on what extra complexity adds to an application, excluding event sourcings as the persistence strategy.



13. John Teague Says:
    April 23rd, 2011 at 8:46 pm

    Sorry couldn’t edit and I wanted to clarify. Please elaborate on the extra complexity CQRS would add to an application.



14. Scooletz Says:
    April 23rd, 2011 at 9:55 pm

    I’m glad you added the part about logging. It’s often used as one of the core advantages of CQRS. The truth is, that using a reasonable data access, you can do it in 200 LOC.
    I do like the style of the whole article, especially the line: “Most 3rd normal form one-to-many and many-to-many relationships simply do not exist when doing SOA and CQRS properly.” It could be a base for another series of articles.



15. udidahan Says:
    April 24th, 2011 at 3:18 am

    Łukasz,

    All of them 🙂



16. udidahan Says:
    April 24th, 2011 at 3:19 am

    John,

    The move to separate stale query stores updated in an eventually consistent manner using pub/sub.



17. udidahan Says:
    April 24th, 2011 at 3:20 am

    Scooletz,

    Glad you liked it – and yes, there is a lot more material to be written.



18. Anon Says:
    April 24th, 2011 at 8:41 am

    I actually had to leave my last job at an otherwise fantastic company because the architects applied loads of distributed systems cqrs split tier high scalability stuff they read on this blog, and I got sick of telling everyone not to overcomplicate our web app. It’s now made of umpteen different websites and backend services and no-one can understand it. I wish you had written this years ago.



19. Steve Sheldon Says:
    April 25th, 2011 at 9:21 am

    Ok, I think with your comment on 16 this is starting to make sense and I agree.

    What we’ve been calling CQRS here internally probably isn’t, it’s more just following some of the patterns with nServiceBus, or a more message driven architecture. From that standpoint I think we see some substantial benefit in reducing complexity.

    I’ve been pushing to get a couple of our developers to attend your class.

    Anon> In post 18 you talk about the complex mess. You can create a complex mess doing any number of different patterns. Good architects should understand when to apply patterns.



20. Zilvinas Says:
    April 25th, 2011 at 1:06 pm

    I’m a big fan of your blog posts but I think that you’re confusing others in what CQRS is.

    The definition of CQRS by Greg Young himself is:

    “CQRS is the recognition that there are differing architectural properties when looking at the paths for reads and writes of a system. CQRS allows the specialization of the paths to better provide an optimal solution.”

    By definition it has nothing to do with Domain Model, DDD, Aggregate Roots, Scalability, SOA, Event Sourcing or Sagas. These things are often used or mentioned together with CQRS, or synergize with CQRS.

    I can assure you that applications that exercise pure CQRS are completely architecturally valid because it ONLY means that queries are separated from commands. This can be as simple as objects which do not contain reporting query methods and only contain methods which change behaviour.

    That by itself is very valuable practice as it helps developers to think about objects as things which have state and behaviour. I’ve seen so much code where objects are nothing but stateless containers of procedural code.

    What I think you do mean with your post and what I think you should have said very explicitly is that people use CQRS, Domain Model, DDD, ES, ED, Sagas all together where it wasn’t needed. Please do not name all these things as CQRS architecture.



21. John Teague Says:
    April 25th, 2011 at 1:41 pm

    Udi,
    Leaving Eventual Consistency aside for the moment, since there is no requirement to use eventual consistency in CQRS. I don’t see how it add complexity to an application, it just moves things around alot (which does take some getting used too).

    In my current project (cqrs in process), command is created, validated, then published as an event and then saved in a denormalized table.

    All of this would have had to happen in a “standard architecture”, but just put into the same place.

    If there is any complexity added, it usually offset with the simplicity of our read model, which is just projections off one of our few view tables (insanely easy).



22. gazarsgo Says:
    April 25th, 2011 at 6:13 pm

    I find it interesting that nobody took issue with what reads, to me, as the most debatable point of all: the very first sentence.

    “It looks like that CQRS has finally “made it” as a full blown “best practice”.”

    Which leads me with great curiosity to ask: what prompted this blog posting?

    For what it’s worth, you should be able to map any architecture to a solution implementation for your business case, and if you can’t, 99% of the time it’s not the architecture that’s at fault, or we’d all be stuck using C/C++. Learn the rules, and immediately start exploring the exceptions to the rules. At the end of the day it’s the right abstraction at the right time that leads us to elegant solutions, not the ability to tout the number of acronyms implemented.

    Personally, I find that messaging systems don’t meet my standards of maintainability, but there are still plenty of concepts I use from CQRS, primarily the ideas of eventual consistency and creating denormalized caches of data for reads.



23. The Morning Brew - Chris Alcock » The Morning Brew #840 Says:
    April 26th, 2011 at 12:31 am

    […] When to avoid CQRS – Udi Dahan discusses when you should not use CQRS type architectures, and how even when using CQRS correctly, it should not be your overall architecture. […]



24. Ian Cooper Says:
    April 26th, 2011 at 5:45 am

    Hi Udi,

    I always think its important to seperate the pattern of CQRS (i.e. seperating reads from writes) from Event Sourcing; CQRS is an enabling pattern for event sourcing, but there is a lot of pain from a layered architecture that can be avoided by adopting a clean seperation of command and query. The most common issue, which I know you are aware of, is the differences between the read and write model. The write model is the ‘rules engine’, the read model the ‘menu’ of choices and using the same model in both contexts is often overcomplicated and unperformant.

    I’d agree that ES requires a domain model that *needs* a full transactional history, but to suggest that there are few such domains is to miss the extent to which business has employed transactional approaches them in a wide variety of domains already.

    I accept the intent of your post: let’s not treat CQRS as a blueprint for anything but a pattern to be applied in a context. But that’s true of everything.

    Ian



25. Roy Dictus Says:
    April 26th, 2011 at 6:06 am

    Udi,

    I think, like many other commentators here, that a CQRS architecture offers many advantages, and for many apps CQRS would be a good choice even if they’re not collaborative.

    Personally, I like the idea of separating read models from write models, and would use CQRS for this reason alone. Mind you: I’m not talking about DDD or Event Sourcing per se, just about pure CQRS.

    An advantage of DDD then is that, when the Domain is properly designed, the business logic becomes very easy to apply, read and modify. This in itself is not related to CQRS, in my view.

    And while Event Sourcing offers the audit trail for free out of the box, for me that is not the “compelling event” needed to choose for this option. I like to use Event Sourcing because it makes persisting any domain model easy and consistent.

    I do use my own CQRS+DDD+ES framework here, which is taking shape, currently for small back-end Web Service projects only, and I like how you can hide complexity in the framework and focus on the important logic in the service code itself.



26. Chris Nicola Says:
    April 26th, 2011 at 4:33 pm

    Ah the old architecture astronaut argument. Honestly I can’t think of too many decent software developers who aren’t for keeping things simple, I can however think of far more who don’t always know enough at any give point to always achieve that (in fact I’d probably say that’s every developer when starting into something new). Knowing when not to use a pattern or architecture is well known to be more valuable than knowing how to use it, but it isn’t a substitute for knowing how. Knowledge of the later is always necessary to know the former.

    Anyone currently confused (as anyone should be on first glance) about CQRS will take this article as a direct argument against ever considering it, as if CQRS is a technology that one might choose whether or not to buy rather than a concept and a tool to be understood and wielded. On the other hand your caution is valid and sensible, albeit I personally feel a bit overstated.

    True, simple systems don’t need CQRS and heck they don’t need n-tier at all. Simple systems also probably don’t need messaging, or SOA, or even anything resembling a traditional domain model at all. But what do these “simple” systems actually look like. How do we recognized and separate what a simple system looks like from a complex one? I don’t agree that it is only based on the need for collaboration. Obviously collaboration will generally be sufficient but I don’t feel it’s necessary.

    Instead I would probably argue that in any system that requires a proper DDD domain model you will find that CQRS offers some noticable degree of simplification when applying DDD principles.

    That said, great post 😉



27. Nuno Lopes Says:
    April 27th, 2011 at 3:42 am

    Hi Udi,

    I found the article to be difficult to read as disparate concerns where put together. Quite often that means good things …

    1) Personally I don’t remember anyone saying that we should put business logic in a separate tier. Is that a requirement of CQRS? On the other hand if we we put business logic behind say a Web Service aren’t we putting logic on a different tier? It seams to me that SOA by definitions makes that point you seam to argue against CQRS so we should argue the same for SOA.

    2) I think overall what you are saying is that from a design stand point most solutions don’t require to separate the data model for reads from the model for writes. One data model for read and write is enough. Current Database Technology allows one specify a set of replicas and have one database for writes and others used for reads We can even state how consistent we want the replicas to be. In this context I fully agree with your assessment.

    3) On Event Sourcing. I agree that event sourcing is not a requirement for CQRS. Yet you seam to justify this with article “There is no Race Conditions” pointing to a way of thinking that side effects don’t exist on CQRS, and in particular to SOA done right. Which I find puzzling considering that the underlying technology over which SOA is built is usually state full.

    4) CQRS is not the only way to separate read models from write models at the data level, at least conceptually. I done that in several occasions with simple non blocking Data Transfer Scheme in production.

    Cheers,

    Nuno



28. Julien Letrouit Says:
    April 27th, 2011 at 5:16 am

    Humm, I agree with Zilvinas. It seems different people are putting different things in the “CQRS” basket. Depending on what your definition is, you can advocate wider or narrower use.

    So which fuzzy keyword could we use to describe the DDD + CQRS + ES + Messaging + Sagas?



29. Neil Freier Says:
    April 28th, 2011 at 10:45 am

    Hi Udi

    My team and I have been learning as much as we can about CQRS in the recent months. We inherited the maintenaince and ongoing development of a large financial application and over the last year or so we introduced various changes like TDD, a more Domain focussed approaced, various architectural refatorings and a massise amount of new features. We don’t feel that CQRS is something that we could implement overnight but we did get lots of ideas by watching videos (yours and Greg’s) as well as reading various blogs and articles.

    CQRS inspired us to seperate Queries/Commands (at a data access level) and do queries via stored proces instead of proprietary ORM stuff. I feel this simplified our project a lot.

    We also started thinking about task based UI’s when doing new work and it really feels a lot cleaner.

    In terms of events we did our own little basic implementation of a command pattern which we currently only used for async stuff but again we feel that it was a great success and resulted in something thats simpler to maintain and even performs/scales better.

    Even with our limited experience with CQRS and DDD I feel that we took a big mess and made it better only by applying some of the ideas that we got by learning about it.

    In some ways this blog confirms what I suspected and in other ways it almost demotivates me. 🙂

    I’ll be moving on to my next project soon and I looked forward to perhaps doing a CQRS implementation from the start by using nCQRS.

    Suddenly I’m no longer sure that it’s a good idea.



30. udidahan Says:
    May 1st, 2011 at 2:36 am

    Commenter 20-29,

    I also joined the discussion on the DDD/CQRS group where I wrote up my response to their reactions there. I believe that it addresses many of your concerns. The link is here, but content copied below:

    If you have separated your code into commands and queries but you
    still have a single underlying data source, I’d call that CQS (or an
    extension thereof) but not CQRS.
    CQRS adds the separation at a data level as well, therefore requiring
    some kind of synchronization mechanism.

    One of the things that did not appear to get much reaction on this
    thread was the statement about CQRS not being the top-level
    architectural pattern (that being SOA). Some recalled my posts on SOA/
    EDA combination (which is correct), others equated SOA with web
    services (which isn’t correct). I’m afraid we might be comparing
    apples to oranges when comparing CQRS (as a full arch pattern) and SOA/
    EDA with some CQRS inside services on an as needed basis.

    One of the big differences is that when applying SOA/EDA at the top
    level, entities tend to get vertically partitioned between services.
    For example, you wouldn’t see a customer’s email address and their
    shipping addresses on the same entity/class. Correspondingly, a screen
    in the UI would also be a composition/layout of “widgets” belonging to
    different services.

    Very complex domains may thus be broken up into multiple small pieces
    to the point where “naive” solutions (as Greg calls them) may be the
    simplest thing that could work (for some of them). It is quite likely
    that you don’t even need a Fowler Domain Model for them. For the rest,
    one characteristic that is similar between them (in my experience with
    many clients/domains over the years) is that of collaboration. When
    you start considering first-one-wins/last-one-wins concurrency is an
    indication that you have a collaborative domain. In these, CQRS can
    indeed make a lot of sense (as I wrote under the “where should we use
    it” heading).

    You can think of this as a rule of thumb – prescriptive, not
    definitive; just like the saga/AR thing:

    “Here’s the strongest indication I can give you to know that you’re
    doing CQRS correctly: Your aggregate roots are sagas.”

    I did *not* say that all sagas are ARs or that all ARs are sagas. This
    indicates that you’re using long-running processes to govern the
    collaboration in the collaborative domains and that you are avoiding
    the use of the domain model pattern in the simple/naive places that
    don’t warrant CQRS.

    One area where the above prescriptive guidance doesn’t hold *as
    strongly* is when developing *platforms* rather than solving a set of
    defined business problems.

    I might say (generalizing, of course) that often people use CQRS where
    they shouldn’t, but don’t use it (properly) where they should.



31. Eben Says:
    May 6th, 2011 at 12:53 am

    Well, as with any technique or technology: if you are go to do it wrong you are setting yourself up for failure.

    I have seen systems that claim to be SOA that simply aren’t, and I can guarantee you that the next vendor approaching the client with a ‘SOA’ solution will probably be shown the door. Why? Because the previous ‘SOA’ bunch sold them a lie.

    I have used CQRS in very simple systems (100% consistency) and it works just fine.

    So either we have a problem in objectively / adequately defining what CQRS *is* or some folks are trying to pluck the pond from beneath the duck!



32. Nuno Lopes Says:
    May 6th, 2011 at 7:42 am

    I wrote a rather long post on DDD CQRS within the scope of this article:

    http://groups.google.com/group/dddcqrs/msg/d68d74a6122fa224?

    After re-reading I noticed some errors of explanation, but hopefully is enough to understand my point.

    On your initial article:

    “Collaboration refers to circumstances under which multiple actors will be using/modifying the same set of data – whether or not the intention of the actors is actually to collaborate with each other.”

    In most business apps we have potentially multiple actors “playing” with the same data. It might be two or 3, it might be a rare occasion but still is within the scope of the word, multiple.

    So still defining the need for CQRS in such terms is a bit vague. You see, if I only have potentially say 3 people interacting with a set of data in some rare occasions why would I even need to separate my reads from writes?

    Considering RDBMS tech that exist today, why such need? For instance we can configure a RDBMS to maintain multiple replicas of the same data model so much as to have one instance just used for transactions and the other instances-replicas use just to serve queries. So why all the pumping? SOA?

    I try to provide a different answer in the post.

    Cheers,

    Nuno



33. udidahan Says:
    May 9th, 2011 at 4:43 am

    Nuno,

    I differentiate between cases where users may occasionally collaborate/conflict and those where it is an inherent property of the domain.



34. Tarek Nabil Says:
    September 17th, 2011 at 2:38 am

    Have you written more about this concept of partitioning an entity among services in other articles?



35. ben Says:
    November 12th, 2012 at 11:35 pm

    Spot on , pity so many people stuff up SOA with chatty distributed services instead of chunky messages and hence have a poisoned view.



36. Tony Says:
    May 18th, 2013 at 12:04 am

    This article doesn’t make any sense to me. Confusing, vague, more like a marketing “scary” move to sell his courses?

    The simple fact of calling “wrong” all the code out there showing the use of CQRS simply shows a very unattractive arrogance not welcome in this community. Are you relative to this Ravendb guy Ayende? You just sound alike 🙂



37. udidahan Says:
    May 19th, 2013 at 12:33 pm

    Tony,

    Registration for my courses has been going very well – I appreciate your concern.

    While Ayende and I are both from Israel, there is no family relation there (that we know of). If you would hear us both speak (in English), you’d notice quite a difference – he has quite a heavy Israeli accent while I have a mid-West Canadian accent.

    Thank you for your comments.



38. ben Says:
    May 27th, 2013 at 5:00 am

    Tony sorry he is spot on .. and the dev community has a habit of overdesigning solutions so should be shocked.

    Agree on most but im not sure of

    1) SOA as the top architecture .. unless your a large organization and you are sharing services amongst developement teams I would say the top should be 2 Tier !. Use assemblies and interfaces for reuse

    2) All AR should be Sagas , i like this but its a pain bringing them into memory



39. nissim Says:
    August 1st, 2015 at 10:58 pm

    At the very least ntier helps to achieve separation of concerns and reusability. I disagree with Udhi that most of the time ntier is not needed. When writing a shopping cart app I want to keep my business logic in a separate dll from the user interface. I want the option of using it to provide for a different user interface if the need arises. I don’t want spaghetti code that mixes UI with business logic.



40. udidahan Says:
    August 4th, 2015 at 11:19 am

    Nissim,

    What you’re describing is packaging of functionality into components – not tiers. Tiers are physical.



41. John Says:
    May 10th, 2017 at 1:48 pm

    Udhi,

    In reference to your comment about shopping carts being an inappropriate case for CQRS, I wanted to ask whether interaction between a user’s shopping cart and a separate bounded context representing an inventory management system might constitute a meaningful collaboration between end users and an internal system actor?

    I’m considering a scenario where the online store is run by a business that has limitted inventory on items from its inventory. The business requires that users are only permitted to place an item in their cart when the projected inventory figures for the anticipated ship date indicate that the item will be in stock when needed.

    When a user adds an item to their cart, the projected inventory should be reduced. If the user’s cart expires, items reserved should be placed back in inventory, and if the cart yields a complete sale, the inventory set aside to account for the add-to-cart operation should remain set aside.

    In reference to your article about race conditions, addressing the above requirements would seem to be similar to the business requirement that orders may be cancelled within the first hour after their delivery. If a shopping cart’s expiration time frame was also one hour, it seems to me like there wouid actually be a great deal of symmetry between these cases, although one involves taking items from inventory and the other involves putting them back.

    In a scenario where the business had no limits on how many orders it could fulfill (or at least none that it cared about enforcing *g*), I would readily concede no collaboration exists. I’ve previously considered CQRS in a context where the business constraint I’ve just described did exist though, and for the very reason that I’ve described above. Should I feel confident or apologetic for my reasoning at the time?



42. udidahan Says:
    September 3rd, 2017 at 11:19 am

    Hi John,

    That does sound more collaborative, though I’d question whether a shopping cart is the right metaphor for that domain.

Your comment...