Udi Dahan   Udi Dahan – The Software Simplist
Enterprise Development Expert & SOA Specialist
 
   
    Blog Consulting Training Articles Speaking About
  

Clarified CQRS

Wednesday, December 9th, 2009.

clarification
After listening how the community has interpreted Command-Query Responsibility Segregation I think that the time has come for some clarification. Some have been tying it together to Event Sourcing. Most have been overlaying their previous layered architecture assumptions on it. Here I hope to identify CQRS itself, and describe in which places it can connect to other patterns.

Download as PDF – this is quite a long post.

Why CQRS

Before describing the details of CQRS we need to understand the two main driving forces behind it: collaboration and staleness.

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. There are often rules which indicate which user can perform which kind of modification and modifications that may have been acceptable in one case may not be acceptable in others. We’ll give some examples shortly. Actors can be human like normal users, or automated like software.

Staleness refers to the fact that in a collaborative environment, once data has been shown to a user, that same data may have been changed by another actor – it is stale. Almost any system which makes use of a cache is serving stale data – often for performance reasons. What this means is that we cannot entirely trust our users decisions, as they could have been made based on out-of-date information.

Standard layered architectures don’t explicitly deal with either of these issues. While putting everything in the same database may be one step in the direction of handling collaboration, staleness is usually exacerbated in those architectures by the use of caches as a performance-improving afterthought.

A picture for reference

I’ve given some talks about CQRS using this diagram to explain it:

CQRS

The boxes named AC are Autonomous Components. We’ll describe what makes them autonomous when discussing commands. But before we go into the complicated parts, let’s start with queries:

Queries

If the data we’re going to be showing users is stale anyway, is it really necessary to go to the master database and get it from there? Why transform those 3rd normal form structures to domain objects if we just want data – not any rule-preserving behaviors? Why transform those domain objects to DTOs to transfer them across a wire, and who said that wire has to be exactly there? Why transform those DTOs to view model objects?

In short, it looks like we’re doing a heck of a lot of unnecessary work based on the assumption that reusing code that has already been written will be easier than just solving the problem at hand. Let’s try a different approach:

How about we create an additional data store whose data can be a bit out of sync with the master database – I mean, the data we’re showing the user is stale anyway, so why not reflect in the data store itself. We’ll come up with an approach later to keep this data store more or less in sync.

Now, what would be the correct structure for this data store? How about just like the view model? One table for each view. Then our client could simply SELECT * FROM MyViewTable (or possibly pass in an ID in a where clause), and bind the result to the screen. That would be just as simple as can be. You could wrap that up with a thin facade if you feel the need, or with stored procedures, or using AutoMapper which can simply map from a data reader to your view model class. The thing is that the view model structures are already wire-friendly, so you don’t need to transform them to anything else.

You could even consider taking that data store and putting it in your web tier. It’s just as secure as an in-memory cache in your web tier. Give your web servers SELECT only permissions on those tables and you should be fine.

Query Data Storage

While you can use a regular database as your query data store it isn’t the only option. Consider that the query schema is in essence identical to your view model. You don’t have any relationships between your various view model classes, so you shouldn’t need any relationships between the tables in the query data store.

So do you actually need a relational database?

The answer is no, but for all practical purposes and due to organizational inertia, it is probably your best choice (for now).

Scaling Queries

Since your queries are now being performed off of a separate data store than your master database, and there is no assumption that the data that’s being served is 100% up to date, you can easily add more instances of these stores without worrying that they don’t contain the exact same data. The same mechanism that updates one instance can be used for many instances, as we’ll see later.

This gives you cheap horizontal scaling for your queries. Also, since your not doing nearly as much transformation, the latency per query goes down as well. Simple code is fast code.

Data modifications

Since our users are making decisions based on stale data, we need to be more discerning about which things we let through. Here’s a scenario explaining why:

Let’s say we have a customer service representative who is one the phone with a customer. This user is looking at the customer’s details on the screen and wants to make them a ‘preferred’ customer, as well as modifying their address, changing their title from Ms to Mrs, changing their last name, and indicating that they’re now married. What the user doesn’t know is that after opening the screen, an event arrived from the billing department indicating that this same customer doesn’t pay their bills – they’re delinquent. At this point, our user submits their changes.

Should we accept their changes?

Well, we should accept some of them, but not the change to ‘preferred’, since the customer is delinquent. But writing those kinds of checks is a pain – we need to do a diff on the data, infer what the changes mean, which ones are related to each other (name change, title change) and which are separate, identify which data to check against – not just compared to the data the user retrieved, but compared to the current state in the database, and then reject or accept.

Unfortunately for our users, we tend to reject the whole thing if any part of it is off. At that point, our users have to refresh their screen to get the up-to-date data, and retype in all the previous changes, hoping that this time we won’t yell at them because of an optimistic concurrency conflict.

As we get larger entities with more fields on them, we also get more actors working with those same entities, and the higher the likelihood that something will touch some attribute of them at any given time, increasing the number of concurrency conflicts.

If only there was some way for our users to provide us with the right level of granularity and intent when modifying data. That’s what commands are all about.

Commands

A core element of CQRS is rethinking the design of the user interface to enable us to capture our users’ intent such that making a customer preferred is a different unit of work for the user than indicating that the customer has moved or that they’ve gotten married. Using an Excel-like UI for data changes doesn’t capture intent, as we saw above.

We could even consider allowing our users to submit a new command even before they’ve received confirmation on the previous one. We could have a little widget on the side showing the user their pending commands, checking them off asynchronously as we receive confirmation from the server, or marking them with an X if they fail. The user could then double-click that failed task to find information about what happened.

Note that the client sends commands to the server – it doesn’t publish them. Publishing is reserved for events which state a fact – that something has happened, and that the publisher has no concern about what receivers of that event do with it.

Commands and Validation

In thinking through what could make a command fail, one topic that comes up is validation. Validation is different from business rules in that it states a context-independent fact about a command. Either a command is valid, or it isn’t. Business rules on the other hand are context dependent.

In the example we saw before, the data our customer service rep submitted was valid, it was only due to the billing event arriving earlier which required the command to be rejected. Had that billing event not arrived, the data would have been accepted.

Even though a command may be valid, there still may be reasons to reject it.

As such, validation can be performed on the client, checking that all fields required for that command are there, number and date ranges are OK, that kind of thing. The server would still validate all commands that arrive, not trusting clients to do the validation.

Rethinking UIs and commands in light of validation

The client can make of the query data store when validating commands. For example, before submitting a command that the customer has moved, we can check that the street name exists in the query data store.

At that point, we may rethink the UI and have an auto-completing text box for the street name, thus ensuring that the street name we’ll pass in the command will be valid. But why not take things a step further? Why not pass in the street ID instead of its name? Have the command represent the street not as a string, but as an ID (int, guid, whatever).

On the server side, the only reason that such a command would fail would be due to concurrency – that someone had deleted that street and that that hadn’t been reflected in the query store yet; a fairly exceptional set of circumstances.

Reasons valid commands fail and what to do about it

So we’ve got a well-behaved client that is sending valid commands, yet the server still decides to reject them. Often the circumstances for the rejection are related to other actors changing state relevant to the processing of that command.

In the CRM example above, it is only because the billing event arrived first. But “first” could be a millisecond before our command. What if our user pressed the button a millisecond earlier? Should that actually change the business outcome? Shouldn’t we expect our system to behave the same when observed from the outside?

So, if the billing event arrived second, shouldn’t that revert preferred customers to regular ones? Not only that, but shouldn’t the customer be notified of this, like by sending them an email? In which case, why not have this be the behavior for the case where the billing event arrives first? And if we’ve already got a notification model set up, do we really need to return an error to the customer service rep? I mean, it’s not like they can do anything about it other than notifying the customer.

So, if we’re not returning errors to the client (who is already sending us valid commands), maybe all we need to do on the client when sending a command is to tell the user “thank you, you will receive confirmation via email shortly”. We don’t even need the UI widget showing pending commands.

Commands and Autonomy

What we see is that in this model, commands don’t need to be processed immediately – they can be queued. How fast they get processed is a question of Service-Level Agreement (SLA) and not architecturally significant. This is one of the things that makes that node that processes commands autonomous from a runtime perspective – we don’t require an always-on connection to the client.

Also, we shouldn’t need to access the query store to process commands – any state that is needed should be managed by the autonomous component – that’s part of the meaning of autonomy.

Another part is the issue of failed message processing due to the database being down or hitting a deadlock. There is no reason that such errors should be returned to the client – we can just rollback and try again. When an administrator brings the database back up, all the message waiting in the queue will then be processed successfully and our users receive confirmation.

The system as a whole is quite a bit more robust to any error conditions.

Also, since we don’t have queries going through this database any more, the database itself is able to keep more rows/pages in memory which serve commands, improving performance. When both commands and queries were being served off of the same tables, the database server was always juggling rows between the two.

Autonomous Components

While in the picture above we see all commands going to the same AC, we could logically have each command processed by a different AC, each with it’s own queue. That would give us visibility into which queue was the longest, letting us see very easily which part of the system was the bottleneck. While this is interesting for developers, it is critical for system administrators.

Since commands wait in queues, we can now add more processing nodes behind those queues (using the distributor with NServiceBus) so that we’re only scaling the part of the system that’s slow. No need to waste servers on any other requests.

Service Layers

Our command processing objects in the various autonomous components actually make up our service layer. The reason you don’t see this layer explicitly represented in CQRS is that it isn’t really there, at least not as an identifiable logical collection of related objects – here’s why:

In the layered architecture (AKA 3-Tier) approach, there is no statement about dependencies between objects within a layer, or rather it is implied to be allowed. However, when taking a command-oriented view on the service layer, what we see are objects handling different types of commands. Each command is independent of the other, so why should we allow the objects which handle them to depend on each other?

Dependencies are things which should be avoided, unless there is good reason for them.

Keeping the command handling objects independent of each other will allow us to more easily version our system, one command at a time, not needing even to bring down the entire system, given that the new version is backwards compatible with the previous one.

Therefore, keep each command handler in its own VS project, or possibly even in its own solution, thus guiding developers away from introducing dependencies in the name of reuse (it’s a fallacy). If you do decide as a deployment concern, that you want to put them all in the same process feeding off of the same queue, you can ILMerge those assemblies and host them together, but understand that you will be undoing much of the benefits of your autonomous components.

Whither the domain model?

Although in the diagram above you can see the domain model beside the command-processing autonomous components, it’s actually an implementation detail. There is nothing that states that all commands must be processed by the same domain model. Arguably, you could have some commands be processed by transaction script, others using table module (AKA active record), as well as those using the domain model. Event-sourcing is another possible implementation.

Another thing to understand about the domain model is that it now isn’t used to serve queries. So the question is, why do you need to have so many relationships between entities in your domain model?

(You may want to take a second to let that sink in.)

Do we really need a collection of orders on the customer entity? In what command would we need to navigate that collection? In fact, what kind of command would need any one-to-many relationship? And if that’s the case for one-to-many, many-to-many would definitely be out as well. I mean, most commands only contain one or two IDs in them anyway.

Any aggregate operations that may have been calculated by looping over child entities could be pre-calculated and stored as properties on the parent entity. Following this process across all the entities in our domain would result in isolated entities needing nothing more than a couple of properties for the IDs of their related entities – “children” holding the parent ID, like in databases.

In this form, commands could be entirely processed by a single entity – viola, an aggregate root that is a consistency boundary.

Persistence for command processing

Given that the database used for command processing is not used for querying, and that most (if not all) commands contain the IDs of the rows they’re going to affect, do we really need to have a column for every single domain object property? What if we just serialized the domain entity and put it into a single column, and had another column containing the ID? This sounds quite similar to key-value storage that is available in the various cloud providers. In which case, would you really need an object-relational mapper to persist to this kind of storage?

You could also pull out an additional property per piece of data where you’d want the “database” to enforce uniqueness.

I’m not suggesting that you do this in all cases – rather just trying to get you to rethink some basic assumptions.

Let me reiterate

How you process the commands is an implementation detail of CQRS.

Keeping the query store in sync

After the command-processing autonomous component has decided to accept a command, modifying its persistent store as needed, it publishes an event notifying the world about it. This event often is the “past tense” of the command submitted:

MakeCustomerPerferredCommand -> CustomerHasBeenMadePerferredEvent

The publishing of the event is done transactionally together with the processing of the command and the changes to its database. That way, any kind of failure on commit will result in the event not being sent. This is something that should be handled by default by your message bus, and if you’re using MSMQ as your underlying transport, requires the use of transactional queues.

The autonomous component which processes those events and updates the query data store is fairly simple, translating from the event structure to the persistent view model structure. I suggest having an event handler per view model class (AKA per table).

Here’s the picture of all the pieces again:

CQRS

Bounded Contexts

While CQRS touches on many pieces of software architecture, it is still not at the top of the food chain. CQRS if used is employed within a bounded context (DDD) or a business component (SOA) – a cohesive piece of the problem domain. The events published by one BC are subscribed to by other BCs, each updating their query and command data stores as needed.

UI’s from the CQRS found in each BC can be “mashed up” in a single application, providing users a single composite view on all parts of the problem domain. Composite UI frameworks are very useful for these cases.

Summary

CQRS is about coming up with an appropriate architecture for multi-user collaborative applications. It explicitly takes into account factors like data staleness and volatility and exploits those characteristics for creating simpler and more scalable constructs.

One cannot truly enjoy the benefits of CQRS without considering the user-interface, making it capture user intent explicitly. When taking into account client-side validation, command structures may be somewhat adjusted. Thinking through the order in which commands and events are processed can lead to notification patterns which make returning errors unnecessary.

While the result of applying CQRS to a given project is a more maintainable and performant code base, this simplicity and scalability require understanding the detailed business requirements and are not the result of any technical “best practice”. If anything, we can see a plethora of approaches to apparently similar problems being used together – data readers and domain models, one-way messaging and synchronous calls.

Although this blog post is over 3000 words (a record for this blog), I know that it doesn’t go into enough depth on the topic (it takes about 3 days out of the 5 of my Advanced Distributed Systems Design course to cover everything in enough depth). Still, I hope it has given you the understanding of why CQRS is the way it is and possibly opened your eyes to other ways of looking at the design of distributed systems.

Questions and comments are most welcome.

  
If you liked this article, you might also like articles in these categories:


Check out my Best Content If you've got a minute, you might enjoy taking a look at some of my best articles.
I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers.
You won't be disappointed.

Subscribe to my feedIf you'd like to get new articles sent to you when they're published, it's easy and free.
Subscribe right here.

Follow me on Twitter Follow me on Twitter @UdiDahan.



Something on your mind? Got a question? I'd be thrilled to hear it.
Leave a comment below or email me, whatever works for you.

126 Comments

  1. Mikael Henriksson Says:

    Great post Udi, thank you for taking the time!


  2. Mark Nijhof Says:

    Hi Udi,

    Very good description. I am intrigued by promoting most all Entities to Aggregate Roots, (at least that is how I understood it) which would mean that now all these need to have Ids unique to the system instead of unique to the Aggregate Root. given this is not really a problem when using GUIDs. One thing is that you lose some of the discountability of having a domain structure, which should not be a big problem either.

    I was thinking that you could by-pass the whole CQRS part when dealing with CRUD operations but indeed it makes much more sense to abstract that knowledge away from the client by having the client sent commands for those operations as well and just handle them in a different way.

    As you may know I am very intrigued by the combination of CQRS and Event Sourcing and am looking forward to your visit to Bergen to discuss the benefits and downsides of such approach. I also hope we can put together a course that I will attend for sure.

    Thanks for the write-up,

    -Mark


  3. Josh Says:

    Very interesting. Just to reiterate…if I get this right….

    Given a situation where two actors send a ChangeAddressCommand for the same customer, an immediate and autonomous answer (the second command being a failure because they need to know someone changed the address before them which requires some sort of merge/cancel interactivity from the user) would be returned since accepting the command also includes the autonomous nature of the DBMS storing the aggregate root?

    Or would you also treat this more like the PreferredCustomer command? If so, how?


  4. Jan Van Ryswyck Says:

    Very interesting article as always.

    You mentioned that you’d go for one event handler per table/view. Isn’t is possible that a view is updated by more than one event or can these event handlers take care of more than one event?

    You also touched the idea about treating every entity as an aggregate root (Customer not having a collection of Order objects – treating both Customer and Order as aggregate root). What about value objects? (Customer having a collection of Address objects?)

    Anyway, excellent stuff!


  5. Jon Says:

    Good article.

    “You don’t have any relationships between your various view model classes, so you shouldn’t need any relationships between the tables in the query data store.”

    How can this be true? Surely in even the most basic systems you always have relationships in the view model (eg Customer > Orders)? How would you query for all customers with orders? How would you do dynamic reporting?


  6. Mark Nijhof Says:

    Hmm spell-check error: discountability => discover-ability


  7. Szymon Pobiega Says:

    Thank you great article. It is nice to have almost all the important things in one place:)

    Here are my questions/thoughts:

    “Therefore, keep each command handler in its own VS project, or possibly even in its own solution, ”

    Its a pity that VS organizes code in such a big and heavy units as projects. Wouldn’t life be easier if we had something like a package in Java? I had many battles in the past with my colleague who thought introducing yet another project into the solution would *drasticly* decrease build time, coding experience etc.

    “Do we really need a collection of orders on the customer entity?…”

    Someone somewhere must create a new order. As you said before (Don’t create aggregate roots) this should be another entity. So it is natural to think about the customer as a creator of its orders. It requires some discipline to use a collection for adding only, but I don’t know any better way to do this (assuming I am using an O/RM). I tend to name the collection “AppendOnlyBlaBlaBla” to make it obvious that it should not be iterated.

    “Even though a command may be valid, there still may be reasons to reject it.”

    How about “DebitAccount” command? It is valid to execute it only if account balance is greater than amount to be debited. Is it the responsibility of the entity or the command to check this? And if it is the entity (my gut feeling, based on the fact that this is not context-free) then how do I communicate the validation error? Using domain events seems to be a good idea, but I am not sure.

    And the last, technical, one. Suppose I have decided to use optimistic concurrency with NHibernate in the command data store and NServiceBus over MSMQ as my transport layer. How could I correctly implement stale data case? NHibernate would throw StaleObjectState exception on me and invalidate its session so I must roll back my transaction which means I can’t reply to my sender using NServiceBus/MSMQ.


  8. udidahan Says:

    Mikael – thanks.


  9. udidahan Says:

    Mark,

    Domain models do end up looking very different when working this way – I’d say they’re more focused. Now that we’ve removed the need to use the domain model for queries, we can also remove unnecessary entities and relationships. Why should there be anything in there besides aggregate roots?

    Event sourcing is indeed a very different discussion.


  10. udidahan Says:

    Josh,

    > the second command being a failure because they need to know someone
    > changed the address before them which requires some sort of
    > merge/cancel interactivity from the user

    Why would the second command fail? If both users are authorized to perform that action, it is a standard last one wins scenario. Think about why this kind of thing would happen in the real world:

    Both me and my wife log on to our account and go to change the address. We’re both going to be putting in the same address – right? So what does it matter that me or my wife changed it before the other?

    With specific tasks, this “problem” isn’t a problem.

    Hope that makes sense.


  11. udidahan Says:

    Jan,

    > Isn’t is possible that a view is updated by more than one event or
    > can these event handlers take care of more than one event?

    With NServiceBus a class can handle more than one kind of event. The thing is that we want cohesion of logic per view model (the thing we’re updating) rather than per event.

    > Customer having a collection of Address objects

    Which rules requires that relationship? I can’t think of a single one. That sounds more like a view/reporting requirement – in which case it would be managed in the persistent view model, not the domain model.

    The command processing AC would publish a UserHasMoved event, and the subscriber could add that address to the persistent view model.

    Not everything goes through the domain model :)


  12. udidahan Says:

    Jon,

    > How would you query for all customers with orders?

    It is questionable that someone is a customer if they haven’t actually purchased anything from us. They may be a “lead” at that point.

    The problem you’re pointing out is one where we shoe-horn the wrong solution on our problem domain. It would be better to explicitly model our entities according to the requirements.

    Leads may turn into customers after they’ve purchased something.

    > How would you do dynamic reporting?

    That often happens in a different bounded context which listens to the events published by other BCs, and stores the data it receives in something like a star schema – designed for dynamic reporting.

    Hope that answers your questions.


  13. udidahan Says:

    Szymon,

    > Someone somewhere must create a new order

    Indeed – one order. What rule talks about multiple orders? Maybe we should just have a property on the Customer entity called OrderCreated containing only a single Order object.

    > How about “DebitAccount” command? It is valid to execute it only if
    > account balance is greater than amount to be debited.

    That’s something we can check against the query store before sending the command, thus decreasing the chance of a failed command. Banks set up a maximum daily transaction/withdrawal limit based on the type of account which minimizes their exposure to risk. Also, they’re usually happy to let an account get overdrawn within certain limits as then they charge interest.

    Finally, even if the command isn’t accepted, there is a record of it – the command doesn’t actually fail.

    In short, the business rules will dictate how this gets handled.

    > In the command data store… How could I correctly implement stale data case?

    You don’t. Commands always deal with the current state. You don’t reconnect disconnected entities to a session. Always get the entities based on their ID.

    Does that answer your question?


  14. Bjarte Says:

    Excellent stuff. I’m looking forward to your Bergen visit as well.


  15. Think Before Coding Says:

    I like the description of the query database as a Persitent View Model.
    Very good post.


  16. Mark Nijhof Says:

    Hi Udi,

    > Why should there be anything in there besides aggregate roots?
    &
    > Not everything goes through the domain model

    This means that you give the reporting model much more responsibility than I would have imagined. I thought that the reporting model was a slave from the domain model, meaning that you could rebuild your reporting model from your domain model. But from what I understand you say, this won’t be true.

    Who is the authority of the state within the domain logic (I would say the domain model)? And the other ‘information’ is just CRUD even if it was changed because of some behavior in the domain?

    -Mark


  17. Mark Kamoski Says:

    While I appreciate the technical rigor of this article, I cannot help but find irony in the fact such is posted under the heading of “Simplist”. As such, I have to formally post an objection along the lines of YAGNI which would, I claim, hold true for at least 99% percent of business applications out there. The abstract idea is good, I admit, and perhaps even “ideal”, however, simplicity dictates that such over-engineering is out of place in real-world software. This is especially when the alleged “problem” can be address by (1) a button “Reload Data”, (2) a label showing “Date Time Data Last Reloaded”, and (3) a last-in-wins commit plan, and (even this is overkill for most) (4) row-level change audit. That is VERY easy to implement and, I daresay, solves 99% of such issues. IMHO, however. Salt to taste. That said, this post is, as usual, quite thoughtful and well done, in abstract terms. HTH. Thank you. — Mark Kamoski


  18. Gilligan Says:

    >This means that you give the reporting model much more responsibility >than I would have imagined.

    I think he means that not all commands go through the Domain Model of the current BC. The UserHasMovedEvent was processed through a Domain Model of a different BC and the current BC’s View Model is subscribed to it.You would still be able to rebuild the View Model from the events by asking the other BC to replay its events when using Event Sourcing.


  19. Gilligan Says:

    Great post, Udi, and one thing you mentioned really got my gears rolling in context with other articles you have posted (about web scalability):

    > So do you actually need a relational database?

    You could save your view model to say, xml files instead of a database. Now we have data that we can serve up directly to web Services and other fun stuff. And we can use the internet itself to cache our entire view model. In fact, you could push it as far to say that the internet itself is your View model Persistence store!


  20. Reflective Perspective - Chris Alcock » The Morning Brew #496 Says:

    [...] Clarified CQRS – Udi Dahan sets out to clarify the meaning of CQRS (Command Query Responsibility Separation) looking at the real meaning (minus any preconceptions from other architectures), and shows where it connects to other patterns [...]


  21. Szymon Kulec Says:

    Greetings:)

    Finally, I’ve found a good article which covers the CQS without additional paradigms such as the event sourcing or DDD. They are important but in my opinion: they are independent.

    The idea of scalability stemmed from “one AC for one command” seems to be the idea of the month. I can imagine raising up the additional machines in places/areas where commands get queued for much to long. I’m curious: have you ever ended with a real one-server-per-one-command and (if you can give that answer) what’s your record if you went deeper into this?

    Have you considered introducing the separation of command handlers when it is needed? At the beginning a system would use the same architecture with relational database (yes it would make ACs and QUERIes use the same db) and when there is a need, a part of the system is refactored into the direction you’ve shown in the article. It might help system be developed quite fast, or maybe I’m wrong?

    Szymon


  22. My name sucks Says:

    blahblahblah… are you an architecture astronaut ? Do you think we need to talk about “collaboration” and “staleness” where in fact it’s just a concurrency problem solved in RDBMS thirty years ago ?

    Why do you want to manage data issues outside of the database management system ? do you want to reinvent the wheel (that is : concurrency control, transaction management…) ?


  23. udidahan Says:

    Mark (16),

    > meaning that you could rebuild your reporting model from your domain model

    Why is that a non-functional requirement of a given system, or of an architectural style in general?

    > Who is the authority of the state within the domain logic

    It is – the “domain logic” / domain model.
    It is responsible for structuring itself in such a way that it has all information that it needs.

    > And the other ‘information’ is just CRUD even if it was changed because of some behavior in the domain?

    I’m afraid I don’t understand this question.


  24. udidahan Says:

    Mark (17),

    > I have to formally post an objection along the lines of YAGNI

    Your objection is noted :)

    > would hold true for at least 99% percent of business applications

    I think that “YAGNI” is very thin architectural guidance.

    > simplicity dictates that such over-engineering is out of place in real-world software

    I haven’t yet heard from you what about the approach I described is “over-engineering”, or possibly you mean that it all is. I’d submit that this approach is probably over-engineered for “hello world” and possibly under-engineered for launching a space shuttle. The qualification you provided in the form of “real-world” seems a bit broad.

    > this post is, as usual, quite thoughtful and well done, in abstract terms

    Thanks – I think :)


  25. udidahan Says:

    Gilligan (assuming 18, 19 is you),

    I’ll defer the topic of event-sourcing to a different post.

    But you’re absolutely right in terms of taking my talks about web scalability and this one together in pushing out the persistent view model over the web.

    It is a very powerful combination.


  26. udidahan Says:

    Szymon,

    One AC per command is logical – you can map a given AC to a single physical OR virtual server. If you have a very heavy load of that message type, you can actually scale out to multiple servers – I have done that numerous times.

    > Have you considered introducing the separation of command handlers when it is needed?

    I don’t recommend this approach when a team is just learning – it turns out that they shortcut the important changes in mindset that are so necessary. After a team has made the change, I haven’t seen a single one that once to go back, so I can’t really speak to it after the fact either.


  27. udidahan Says:

    To poster 22, “my name sucks”,

    While I allow posts from anonymous people, I rarely respond.

    To your assertion that RDBMS technology has solved all the problems raised in this post “30 years ago”, it is interesting that so many of my clients who use RDBMS technology still have issues. When speaking at conferences, I hear from hundreds of people that they have these very same issues.

    It could be that you know some secret about the use RDBMS technology that the rest of us don’t – if so, please write it up somewhere and enlighten us.


  28. Ayende Rahien Says:

    > Maybe we should just have a property on the Customer entity called OrderCreated containing only a single Order object.

    *puke*, that is seriously abusing the tooling in order to avoid having assoications in the domain model.
    I would rather call Save() directly than that, or better yet, have a Orders collection on customer that we can Add() to.
    That gives us a very natural model to work with, with no hacks.


  29. Nuz Says:

    Thanks for the post!
    Ok let me see if I understand this:
    We have a customer aggregate root and and an order aggregate root and
    in a RDBMS database the order table has a FK constraint to the customer table.

    In my current DDD understanding I have an Orders collection property in the Customer entity.
    On my screen a user can bring up a customer’s information and all their orders. The top half contains the customer info and the bottom half contains the orders in a grid.
    I use a fetching strategy to make a call to the Customer’s aggregate root and in the “Domain Service” layer that belongs to the Customer entity, I make a call to the Order’s aggregate root to fetch all the orders for that customer. This way I do not dirty my Customer entity with information that pertains to another entity. (My goal is to have th Customer entity only worry about its data and behaviours and deal with things that pertain to it only).

    So thats the background.
    In a CQRS model, my questions are:
    1. Would I issue two queries, one that would get the customer information and the other that would query all the orders for that customers?
    2. So the user now updates some information on the customer and also updates something to do with orders in the grid, would I then issue two commands? One to update the customer information and the other to update the orders information?

    Sorry for the rambling but I just want to clarify.

    Regards


  30. udidahan Says:

    Ayende,

    Notice that in my post I said:

    “Maybe we should just have a property on the Customer entity called OrderCreated containing only a single Order object.”

    Where the qualifier “maybe” indicates that this isn’t *the* solution, but rather a question that one should ponder.

    The purpose of a domain model is to capture the rules of business, and we should be looking at structuring it that way.

    > that is seriously abusing the tooling in order to
    > avoid having assoications in the domain model.

    Maybe we need different tooling – a familiar story :)

    > have a Orders collection on customer that we can Add() to.
    > That gives us a very natural model to work with, with no hacks.

    Sounds like you’re suggesting to warp the structure of our solution to be natural *for the tool*, rather than the problem at hand, which is an odd position for you of all people to take ;)


  31. udidahan Says:

    Nuz,

    > I make a call to the Order’s aggregate root to fetch all the orders for that customer

    In CQRS, you wouldn’t use an aggregate root for fetching. That would be done against the query data store – which may well be an in-memory cache, or an XML file on a CDN like Akamai, or its own DB.

    > 1. Would I issue two queries, one that would get the customer
    > information and the other that would query all the orders for that customer?

    Well, you’d issue 2 queries against the query data store, yes.

    > 2. So the user now updates some information on the customer and
    > also updates something to do with orders in the grid, would I then
    > issue two commands?

    Well, you’d probably not have the user updating information on the same grid as the one that is used to show them the data, but generally speaking, the answer to your question is yes – 2 commands.

    > One to update the customer information and the other
    > to update the orders information?

    Depending on how many orders the user changed, you may have one command per order that was changed – or multiple commands even for a single row:

    DiscountOrderCommand
    RerouteShippingForOrderCommand

    Hope that answers your questions.


  32. Zilvinas Says:

    Thanks for the post! Very interesting.

    More of a general note.. I’m not sure you meant table module AKA active record. In fowler’s catalog they belong to different groups. Table module is about how you design your domain logic and active record is a data access pattern. Maybe there is a general understanding of AR as table module of which I don’t know about. They have some similarities such as having a class per table but in AR it’s an instance of a database row with business behavior while a table module is something different.


  33. Monday Roll-Up – December 14, 2009 « christopherDeweese.com Says:

    [...] Udi Dahan gives us more insight into his “Command Query Responsibility Segregation” diagram [...]


  34. udidahan Says:

    Zilvinas,

    You’re correct.


  35. Dan Robinson Says:

    I’m very interested in exploring this approach, but I’m still unsure about a few things. How does the query cache get populated at start-up? Once the cache is up to date with the database, I can see how published events from the command AC will keep it in sync.

    Does the query AC need to send a “get all” message to the command AC at startup? Although, wouldn’t that force the command AC to implement query logic?

    Along similar lines, what if the database is so large that it would be impractical to keep all of the information in the query cache at the same time? Is it necessary to scale the query cache with distributed hash tables or even separate databases in order to hold everything in the query AC? Is it allowed for the query AC to fetch information on demand if necessary? How would it fetch the information?

    Is the query AC allowed to read directly from the database? I suppose that would solve the problem, but I don’t know if that violates the autonomy of the two components.

    Oh well, I appreciate your insight. I’m still trying to get a clear picture of how all of this stuff fits together. Thanks.


  36. udidahan Says:

    Dan,

    The query cache is durable, it can be a database in its own right.


  37. Command and Query Responsibility Segregation « Dotsystems Says:

    [...] an InfoQ: Unshackle Your Domain. The fullest exposition can be found in Udi Dhan’s post Clarified CQRS. There was a lot of discussion on Domain Driven Design Yahoo group so it is also a good source of [...]


  38. jmorris Says:

    Wow, this is one of the most interesting architectural articles/blogs I have read in some time. It’s really got me thinking about CQS. Thanks!


  39. Archil Says:

    Is there any guidance for building Task Based UI?


  40. Elegant Code » A web store using FubuMVC and CQRS Says:

    [...] something then driven by actual usage. I am also thinking about incorporating Udi Dahan’s thoughts into this by not making my aggregate roots into huge tree structures, but by keeping it as flat as [...]


  41. Henning Anderssen Says:

    Great article.

    how well would this approach work with crud systems or in business applications with few complicated business rules?


  42. Mark Phillips Says:

    Hi Udi,

    A few questions based upon a hypothetical scenario to understand the impact of eventual consistency in CQS where the query store is not part of a command’s unit of work:

    The simple (hopefully) scenario:
    Picture a command called CustomerSubmittedApplicationCommand sent to a domain model operation thereby publishing a domain event that will set the object’s KPI date property. The date value to be provided to the domain event (CustomerCreatedNewApplicationEvent) for its KPI property is say 30 business days from today.

    We have an object that manages dates that are not to be included when determining numbers of business days between 2 dates and provides queries for calculating a date given a delta of business days and a start date.

    Questions:
    1. In CQS is the BusinessDayCalculator part of the domain given that it is used for querying against to supply domain logic with information?

    2. If 1. is false should it be part of the Query-side given it is not used in any view or report but only the domain logic?

    3. Regardless of which side of the fence it sits, do I use a service layer/locator or DI?

    4. And the crunch question…if the non-business days are supplied to the domain by users submitting UserInsertingNewNonBusinessDateCommand and the domain uses the query side for returning a calculated date based on business day deltas and we are now utilising “eventual consistency” on our query side for scalability of our writes, is there not a possibility that a KPI could have been set incorrectly due to the NewNonBusinessDateDomainEvent not flowing into the query side in time? I guess another way of asking this question is should the domain query itself always rather than the query side generally but especially so in the context of Eventual Consistency?

    Mark


  43. Jon Says:

    Udi, what is your take on how the domain might check that a username is unique in a validation scenario?

    http://bjarte.com/post/224749430/set-based-validation-in-the-cqrs-architecture


  44. udidahan Says:

    Henning,

    I’d say that assuming ahead of time that a system is CRUD or has few rules may not be a good place to start. When talking with users of business applications, I’ve always seen many rules come out. You see what you want to see.


  45. udidahan Says:

    Mark,

    Your BusinessDaysCalculator is a component that can be used in both sides of the architecture.
    That being said, I’d look at having business days be represented by your own value type, possibly with two fields – reference DateTime and number of business days.

    Hope that helps.


  46. udidahan Says:

    Jon,

    The domain wouldn’t check that – just use a unique constraint in the DB. For better performance, I’d have the UI access the Q store before sending the command to check if the name is already taken.

    The domain model is responsible for rules that are likely to change – username uniqueness isn’t likely to change.


  47. Mark Says:

    Hi Udi,

    I think I was hoping to make the calculated date to be immutable and calculated once which makes it immune to further non-business days being added. Regardless, the questions were more about the effects of eventual consistency on a query store.

    If a domain aggregate needs information from the domain but outside the aggregate (I used the business day calculation component as an example), should it be targeting queries for this information at the query store and if so what happens if the query store is eventually consistent?

    Thanks,

    Mark


  48. udidahan Says:

    Mark,

    Business day calculation is a technical component – not a part of the domain.

    “If a domain aggregate needs information from the domain but outside the aggregate…”

    … then the structure of the domain needs to be rethought so that doesn’t happen. It should not make any calls to the query store. This may require a different style of functional analysis than some people are used to.

    Hope that makes sense.


  49. Mark Phillips Says:

    Thanks Udi that makes a bit more sense but as always answers lead to further questions ;-)

    I think I was looking to see if there was a view of the system on the query side such that all information required in a viewModel could be provided by the denormalisation process but I’m thinking this isn’t the case. As you said, business day calculation is a technical component and available on both sides and needs to be if the user must see, for example, Days Remaining. I guess I don’t know how far to take the “denormalisation”.

    I have other technical components also that I’m thinking don’t fit into the denormalisation process, one that integrates task management onto aggregates to determine if a command can be executed by the user. It’s pseudo ACL at the command level on an aggregate using a direct User association to the aggregate in the context of a command, plus the ability to infer association by membership to another object (assuming that object implements a membership interface) associated with the aggregate. For example, a Region instance (R1) is associated with an Aggregate instance (A1) in the context of a Command (C1). If a user is a member of R1 then they can execute the command C1. This is also used to only allow specific user access to the query-side in the context of aggregates – restricts users views to only their associated information.

    Whilst management of the associations is part of the domain, providing a denormalised view of who can execute X command on a specific aggregate through inference of their membership to a Region would potentially result in a lot of data in a denormalised view and thus also require many view record changes if say the aggregate was associated with another Region. Do you agree?

    So, I’m thinking that from the query-side perspective, it’s not always possible to push the ViewModel structure completely into the database structure via the denormalisation process?

    It then follows that if your query-side is performing calculations over recordsets to support the views requirements the speed of the query is dependent upon the speed of any calculation over a column in the recordset and thus you lose much of the benefit of having a dedicated query-side. Your thoughts please?

    Regards,

    Mark


  50. Timothy Walters Says:

    Mark,

    In your scenario, wouldn’t the processing of a UserInsertingNewNonBusinessDateCommand require any existing KPIs to be re-processed and have their end-date and/or days left modified accordingly?

    I would think that the NewNonBusinessDateDomainEvent would fire and require retro-active changes, or at the least re-calculations of existing KPIs.

    Timothy.


  51. udidahan Says:

    Mark,

    Your client side could also make use of your calculator component on top of the data provided by the persistent view model.

    If you want to “determine if a command can be executed by the user”, that is a query operation done to a separate bounded context (Security) that is plugged in as an intercepting filter to the regular message processing pipeline.

    The part that comes after the above in the pipeline actually does the command processing.

    This probably is too much to describe in comments so I’ll put up a separate blog post on the topic


  52. Mark Phillips Says:

    Timothy,

    I agree that to keep the domain consistent this would need to happen.

    Mark


  53. Mark Phillips Says:

    Udi,

    Agreed that the “determine if a command can be executed by the user” query is part of a guard/security preceding the command processing. I’ve always thought this is the case.

    However I need to enhance the user’s experience of the Query-side by providing filtered commands rather than allowing a user to send all commands and have them fail upon sending. For example, if a user does not have the correct Command ACL for changing a specific Customer’s address then don’t present them the link in the first place. The alternative and less desirable way is to present the ChangeAddress link regardless of ACL, let them make the change, send the command and then fail.

    I’m trying to determine if the UI should ask for the available commands given an aggregateroot id and the user context or if the command information should be provided as part of the query result, be it for a single aggregate or a search returning multiple aggregate roots as summary records.

    If the UI asks for available commands then regular query performance is not impeded but we may end up with a very chatty UI to service interface. If we try and shoe-horn this data into the viewmodel as part of the query then performance suffers. I’m thinking that as the ACL isn’t really part of the domain then it shouldn’t be a part of the ViewModel concerned with domain information, the information is itself a different view of another context?

    In the past I would have composed the viewmodel with this extra detail so that the UI can bind to the respective command buttons for visibilty.

    I like the concept of CQRS very much but need to understand it fully in the context of the user experience so thanks for taking the time to answer my questions.

    Mark


  54. Roy Says:

    Ah… so it’s that simple. Wow… Tunnel vision is a bitch. I had only seen this implementation used with event sourcing so I was beginning to think that it should only be done that way.

    I have to remind myself to take a step back and look at what the solution is trying to solve versus getting burried in the code details prior to.

    Thanks, Udi.


  55. udidahan Says:

    Roy – yeah. Simple is good :)


  56. Jon Says:

    How can you deal with batch processing that requires a query?

    We have a situation where we need to execute a process on a batch of entities based on some criteria. We can ask the query side for a list of ids, individually load up the entities and process them. This seems very inefficient. Is there a better way? Is it “ok” to query the domain in this scenario?


  57. Living in the Tech Avalanche Generation » Finding my way with MongoDB and C# – Part 1.0 Says:

    [...] on the query side in a CQRS architecture for instance, serving as a store for directly bound view model data. MongoDB at first glance offers some nice features that would blend well into an architecture [...]


  58. Andrew Deakins Says:

    Hi Udi,

    Great to read and finally understand the essence of CQRS. My only fear is that how do you deal with command explosion? for instance there maybe a hundred different reasons why somebody would change their name and having a command indicating the intent of each and every one seems a little silly.

    I guess with most things a little common sense applies here correct?


  59. udidahan Says:

    Jon,

    It is likely the batch processing that you’re describing isn’t a command in its own right, rather it is a batch of commands, where each can succeed or fail independent of the others.

    On the other hand, this can be an ETL-style thing, in which case the previous statement may not hold.

    I’d deal with the above questions before looking at efficiency. If the former is the case, you can parallelize the execution of commands, even if it appears inefficient at first blush.

    Hope that helps.


  60. udidahan Says:

    Andrew,

    Our goal is to identify along with our business stakeholders which user intent is significant. If your business logic has ‘if’ statements to do something about a given scenario, it is likely that we need to introduce a command for that. Typing more commands is the least of our worries.


  61. andyb Says:

    Udi,

    you suggest to let a db constraint check uniqueness as in comment #46. in case of a violation the db provider throws an exception. Typically exceptions causes msgs to get poisoned, which causes retries, which maybe succeed if the value becomes availible but ultimatly the msg will go to an error queue. but in case of a unique constaint violation there is hardly anything an admin can do with the msg in the error queue, rather its a “normal event”. also some component has to catch that and notify the user somehow.

    my question is: how do you handle that?


  62. udidahan Says:

    Andyb,

    Then we would have a try catch for that specific type of exception in that handler :)


  63. andyb Says:

    yeah, that’s the obvious part, but what to do in catch to notify the user?

    you suggest before to only rely on exceptions in exceptional situations (like db not available), but is this the case here? as i said an unique const violation is normal behaviour (like email adr must be unique), isn’t it?


  64. udidahan Says:

    Andyb,

    If we don’t have any other means to communicate with the user, like another email address (Yahoo does this), let’s say we did nothing. This is a rare occurrence – a race condition between two users for the same email.

    What is likely to happen is that the user will try to login at some time in the future, won’t succeed, and will re-register (or give up).

    In the case they give up, saving this one user in a million probably isn’t worth the cost of doing so. Even though I’m guessing that that’s an answer you don’t want to hear :)


  65. Leonardo Says:

    Udi,

    How would you see integrating this with Comet, in order to make the result from the repo db appear in the same page where the command was requested? Does this scale? Is there any disadvantage of using this approach?


  66. udidahan Says:

    Leonardo,

    I don’t think Comet is needed for that – some simple browser side javascript (aka AJAX) can take the data that was submitted in the command and append it to the results from the query side. As this is browser side, it brings no scalability overhead. Hope that answers your question.


  67. Leonardo Says:

    Yeah, but if the data is needed as soon as it is submitted, I may call the query before the event was handled, so I would not retrieve the changes, but the same state as before. In this case, I only think about polling. Maybe the query could return together with the results the date and time it was last updated, so when that changes, i stop polling.

    What would you do in that case?


  68. udidahan Says:

    Leonardo,

    If the data is needed by the client as soon as it is submitted, it is there – on the client that submitted it. No need to poll the query side. The only thing that might not have been there is an ID from the database – which is easily solved with client-generated GUIDs instead of database-generated IDs.


  69. CodEagle » CQRS && Validation && Business Rules Says:

    [...] for itself yet. Proposal: “Circular Architecture”? [3] This is explained nicely in this post by Udi Dahan. Search for “Commands and validation”. [4] An explanation can be found in a fine post [...]


  70. What is the Ncqrs Framework? Says:

    [...] Clarified CQRS by Udi Dahan [...]


  71. ToddM Says:

    Excellent article. I always found it unrealistic to always use the domain model for views when it’s so much more efficient to go directly to the database and query for exactly what you need. But it’s always felt dirty to pollute my domain objects with view-specific queries. Here finally is a pattern that acknowledges the problem and deals with it elegantly. Very enlightening.

    I’m considering simplifying one aspect of this pattern in my initial implementation. I’m using SQL Server for my main data store. Rather than creating a separate physical query store, I’m going to create a set of view-specific indexed views and stored procedures in the same database. I’ll use a separate SQL Server schema (named QueryStore, or something like that) and a separate connection string in my config files. This way I don’t need worry about synchronizing the query store – it’s done automatically. View indexes and object-level locking should help with performance, but if the day comes that I need to scale my query store out to its own database/server, I should be able to do so without major re-architecture of other components of the system.


  72. Tacidic Says:

    Great article Udi. Quick question for you: if you’re updating the OLAP db whenever a change occurs (i.e., all the time) and you’re querying the same db (all the time) aren’t you just shifting the bottleneck?


  73. udidahan Says:

    ToddM,

    Glad you liked it.

    You don’t necessarily need to include the cache-updating AC if you implement your query store as views on top of your domain store. Keep in mind that this doesn’t mean you can skip thinking about the level of staleness that the business is willing to live with.

    All in all, sounds good.


  74. Olav Rask Says:

    Hi

    If anybody (Udi? :) ) is stil following comments here, can someone elaborate a bit on how to keep the read site up to date?

    Say I assign a user a new role, resulting in a UserAssignedNewRole event containing the UserId and RoleId. When i go to update my “UsersWithRoleName” read-side table, am i suppose to have the roles stored seperately on the read side, in order to find the role name, to put in?

    This could potentialy mean storing the entire model as well as the denormalized tables on the read side.. ..would you recommend this or do you have an alternate approache?

    Kind regards
    Olav


  75. Hendry Luk Says:

    Great article Udi. This is definitely one of the most comprehensive articles ever written in CQRS topic.
    There are however some bits where I feel like you make a big deduction leap that I can’t quite follow.

    ["And if we’ve already got a notification model set up, do we really need to return an error to the customer service rep? I mean, it’s not like they can do anything about it other than notifying the customer."]
    IMO you’re making too many “if” assumptions in that deduction. Let’s branch the hypothetical a bit and take another real-world case where an attempt to place an order is invalidated because the combination of the selected handset/service/contract-type is not available. The sales rep will *need* to be notified “synchronously” about this, so he can try again with a different combination that are valid according to the business-rule (by talking it through with the customer of course). Order-submission is a command, and it *is* expected to give an immediate feedback to the sales rep upon its failure/success.
    Another highly common example is to perform credit-check via an external institution before allowing the sales-rep to progress further into product selection screen, or perhaps limitting the product selection to certain amount of value, based on the customer’s credit-rating calculated by the legal institution. A request to perform a credit-check via a legal institution is a command, and again, an immediate feedback to sales-rep is expected.

    ["Do we really need a collection of orders on the customer entity? In what command would we need to navigate that collection?"]
    In the commands where we might perform business-rule to apply certain logic if customer’s total orders have exceeded certain value. Probably doesnt make sense in this case since customer and order are probably 2 different aggregate roots. But more sensible in the case of order and order-items (e.g. “checking that all order-items within the order are within certain threshold”. Or, “if all the order-items within a single order are delivered to a maximum of 3 different addresses”).


  76. udidahan Says:

    Hendry,

    I’ve answered some of these questions as presented on the DDD discussion group.

    On the issue of collections, line items in an order need not be accessible outside of the order. We can handle the customer’s total order value with a property on the customer entity that is updated on each order. This structure would more closely reflect the language of the domain too.

    Hope that helps.


  77. CQRS isn’t the answer – it’s just one of the questions Says:

    [...] the growing interest in Command/Query Responsibility Segregation (CQRS), more people are starting to ask questions about how to apply it to their applications. CQRS is [...]


  78. Tarek Says:

    I think I have sort of the same question that Mark Philips raised and I feel like the answer is not that clear yet (at least for me). I believe it goes down to the concept of a bounded context. It’s not so easy to partition your domain into clear cuts and one of the areas which will always be shared is reference data.

    I’ll try to provide a simple example: Suppose I have two ACs; one handling customer registration and another handling order submission. They both depend on one piece of information; whether the user’s country is part of the EU. In the registration case, we’d like to give the user a discount if he’s in the EU and in the orders case, the shipping costs will depend on that piece of information.

    Definitely, the information about a country being in the EU is not contained within the registration or orders contexts. So the question is: Should those ACs request such information from another AC?

    In essence, should ACs direct their data queries to other ACs?

    Thanks


  79. Matt S. Says:

    The thing I still struggle most with with CQRS is how to handle a “mixed system”. For example, suppose some views are collaborated on by multiple actors, but other views are the responsibility of a single user.

    Udi, you commented above that if your wife and you both change your account address, it’s okay for the system to apply both commands. I get that, but how do ensure that the data is not stale if you forgot to change something on your account moments later? If your change address command is not issued synchronously (or at least nearly immediately), you’ll see the old address (from cache) on your edit account view. Being a user, you’ll scowl and mumble something to the effect of, “I just changed my address! Why is it still showing my old address?”

    What do we do in the cases of our users self-editing information in the system that they expect to see freshly updated?


  80. udidahan Says:

    Matt,

    If this is a web system, put that information from the command in the cookie and then overlay it on the data retrieved from the query side. You can do similar things in smart clients.

    In that way, it won’t show the old address when the user looks at it, irrespective of the fact that the query side is delayed.


  81. Matt S. Says:

    That makes sense; a cookie or lightweight session data. Thanks, Udi.


  82. Mikael Koskinen Says:

    Hi and thanks for a great post. I have a small question about publishing the events (for example to the handlers which update the query side).

    “The publishing of the event is done transactionally together with the processing of the command and the changes to its database.”

    Is it the right way to publish the events in the command handlers? So for example, should our ClientMovedCommand look something like this:

    var client = repository.Get(movedClient.id)
    client.MoveToNewAddress(addressDetails)
    bus.Publish(ClientHasMoved)

    Or should the publishing be done in somewhere else? I can think of an alternative approach:

    CommandHandler -> Client.MoveToNewAddress -> (inside the domain model) DomainEvents.Publish(ClientHasMoved) -> ClientHasMovedEventHandler -> bus.Publish(ClientHasMoved)

    Thanks in advance.


  83. udidahan Says:

    Mikael,

    If the event being published is just a statement that the command was processed successfully (like the MoveClient – ClientHasMoved case), then do that in the command handler.

    If the domain model raises an event about something else that has happened in addition to the performing of the command, than that would work with the domain event handlers, which then Bus.Publish.


  84. Tom Says:

    Olev,as far as I understand this is done by using a domain model

    events

    Or better ,a service layer(an upper layer) events

    The changes are published to the right most AC(a bus,a queue?)

    And a translator translates the message to a form which is known to

    The cache

    I still don’t understand though how the cache can be initialized

    With a domain object’s computed field

    Assuming a computed field isn’t backed by a persistent storage

    And also it is not clear to me the correct boundries of a transaction

    How would i ensure consistency of the cache and the master DB?

    :( i am having problem with the captch once again


  85. udidahan Says:

    Tom,

    In my more recent presentation I’ve stopped calling it a “cache” preferring instead to call it a “persistent view model”. As such, it doesn’t need to be initialized.

    The update of the “master DB” is one transaction, and the update of the persistent view model is another transaction. You usually don’t require consistency across them both every microsecond.


  86. Race Conditions Don’t Exist Says:

    [...] seeing is that cancellation is now a command that has no reason to fail – just like CQRS tells us. When this command is performed, it publishes the OrderCancelled event, which the billing [...]


  87. Maninder Batth Says:

    Udi,
    Your article has spawned some doubts. Here are my concerns :-

    1. Promoting entities within aggregate as root entities :- The concept of aggregate is to maintain invariants within the boundary of the aggregate. If i start treating entities, that have local identities within an aggregate as root, the concept of maintaining invariants would probably have to be isolated as an aspect of it’s own. Then the commands would be validated through aspect and the entity, which is just a different representation of root and the entity concept.

    2. Validation within commands :- There are 2 concerns here.
    First, if both commands and domain are to perform validation (as you mentioned, that commands from UI are not to be trusted) , would it not result in performance degradation?
    Second concern is that domain model may become anemic. Consider Syzmon’s example above
    “How about “DebitAccount” command? It is valid to execute it only if
    > account balance is greater than amount to be debited.”
    You replied
    “That’s something we can check against the query store before sending the command, thus decreasing the chance of a failed command. Banks set up a maximum daily transaction/withdrawal limit based on the type of account which minimizes their exposure to risk. Also, they’re usually happy to let an account get overdrawn within certain limits as then they charge interest”
    I really see the above as business rules, which should not be exposed at command level. Hence, i see business logic being spread between commands and domain, resulting in an anemic domain and coupling between commands and business logic.

    3. Having each handler to be it’s own project :- consider various scenarios for modifying an entity. Each scenario will result in an intention revealing command as opposed to a generic update entity command. Having each of the possible command handler in it’s own project seems to be an overkill.


  88. udidahan Says:

    Maninder,

    If the article spawned doubts – that’s a good thing :)
    The goal is to get you thinking.

    Part of the issue you seem to be having is the assumption that all business rules need to be handled by the domain model. In the description of the domain model pattern it states that it is responsible for handling the rules which change often – not *all* the rules. In the example you mentioned, do you expect that the bank will change often the rule about letting debit accounts get overdrawn? I expect not. As such, this rule doesn’t necessarily have to be implemented in the domain model.

    About your concern that this will result in an anemic domain, in my experience it does not, but that the domain ends up looking different from what you might have originally expected – being more about long-running processes than about any single command/entity behavior.

    When using sagas for these processes, you don’t need an additional handler – so no additional project :)

    Hope that helps.


  89. Tom Says:

    Udi

    Still how would the ‘persistent view model’ gets updated with a domain model computed field
    A field which is not backed by a persistent storage and only computed When a change to the domain model occurs.
    As long as the domain model isn’t getting into action the persistent view model wouldn’t get updated.

    If the update of the “master DB” is one transaction and the update of ‘persistent view Model’

    Is another one, what will happen if an update of ‘persistent view model’ consistently failed?

    MSMQ can ensure retrying the update but what if the update violates some constraints defined in the ‘persistent view model’

    Shouldn’t we roll back the “master DB” transaction or at least cache those failures and notify?

    Thanks


  90. udidahan Says:

    Tom,

    Why do you assume that values computed by the domain model aren’t persisted there? Arguably these computed values are actually the most interesting things in the domain representing most closely the language of the domain experts.

    If an update of the persistent view model failed (threw an exception), it would be retried a configurable number of times and then sent off to an error queue, which an administrator is likely monitoring. This tends to happen most often when installing a new version of something as the kinks are worked out of the system – it very rarely happens otherwise.


  91. Tom Says:

    On the contrary, I know the computed fields persisted in the ‘persistent view model’
    But I assume they are not persisted on the “master db”

    So in order to initialize the ‘persistent view model’ for the FIRST TIME,I need to use the domain model In order to compute all computed fields

    Thanks


  92. Maninder Batth Says:

    Udi,
    Thank you for the response.
    I am understanding your response as follows :-
    Put volatile(prone to change) business logic in the domain object and put logic that does not change frequently in some “Thing”. Can you please describe what would be that “Thing” that would contain non volatile rules?
    Perhaps an example can clarify my question.
    Consider an entity, with a certain behavior. The behavior would be satisfied by either volatile rules, or non volatile rules or combination of both.
    The behavior is described by an Entity’s interface.
    So are you implying that the implementation of that interface should be split into 2 objects, a domain object that manages volatile aspects and some “Thing” that manages non volatile rules related to entity’s responsibility?

    What confuses me is that i am used to thinking in a traditional OOAD. Hence, i would typically assign responsibility to where it belongs, regardless of the frequency of change. The internal implementation will care about frequency of change and hence perhaps externalizing to scripting, rules, db etc, but thats internal details.


  93. udidahan Says:

    Tom,

    Some computed values may indeed be persisted in the master db, others which are simple aggregations (like sums) that are only needed for views can be computed without the domain.


  94. udidahan Says:

    Maninder,

    The other thing (or multiple things) could be in the validation component and/or the controller for the command making use of data in the persistent view model to decide not to send a command. In short, it’s not on the entity and not part of the entity’s interface.

    I understand that this doesn’t follow traditional OOAD, but I’ve found it extremely effective.


  95. Michael Leung Says:

    Udi,

    I am practicing DDD and agreed that the query portion (or context) is unnecessarily complex. However, queries are not always simple relational retrievals. Take stock’s weighted average cost as example. It may need to navigate a lot of entities, executing these entities’ methods before arriving at the cost for the stock. The query does involve Business Rules and behaviors exists in Queries, not just in Commands.

    If all unit costs are pre-calculated in the cache, then we may be doing more than necessary. How to deal with this?


  96. udidahan Says:

    Michael,

    What you’re describing is handled by a “calculation component”, a pure functional component that doesn’t access any data on its own but is fed data from the outside. The client passes in the data from the persistent view model into the calculation component and displays the results of the calculation. The query itself remains very simple, although the calculation itself may be quite complex.


  97. Michael Leung Says:

    Hi Udi,

    Thanks for your explanation. It so happens that the “calculation component” is one of the stock’s business methods and it is used in commands such as “Create purchase order”. This business method can navigate from itself to its purchase histories, shipments, exchange rates & etc. Because Hibernate will do all the OR mappings, we don’t need to pre-fetch all the required histories, shipments, exchange rates and past them to the “calculation component”.

    For CQRS, do I need to duplicate the business method’s logic to the “calculation component”? (same logic, different implementation because one based on ORM and another is functional component with pre-fetched data sets as parameters)

    Regards,
    Michael Leung


  98. udidahan Says:

    Michael,

    It sounds like that calculation component is doing too much, violating the single responsibility principle.


  99. Michael Leung Says:

    Hi Udi,

    Actually, the method is an aggregate root (Stock) method, which can naturally navigate its childs to do calculation. The method has only one responsibility – to calculate the weighted average cost of the root entity.

    Anyway, thanks for your insights.

    Regards,
    Michael Leung


  100. Maninder Batth Says:

    Udi,
    When not to use such an approach?
    Should this approach be used for applications that can meet their read objectives through a normalized database structure ?


  101. udidahan Says:

    Maninder,

    I’d say that if the data does not need to be operated on by multiple actors collaboratively, then you might not need this approach. Highly complex non-collaborative domains may need it as well.


  102. maninder Says:

    Udi,
    It seems like my last comment was not published. So let me retry hoping it is an idempotent operation :)
    With my limited understanding, i see CQRS as a mechanism to scale read and writes.
    Can you please explain how multiple actors collaboratively or highly complex domain can benefit from it GIVEN the constraint “The reads and writes in that application do not need to scale independently”.


  103. udidahan Says:

    Maninder,

    The technical form of using one-way commands enables scaling writes, and serving reads off of a type of cache has alway sbeen a way to scale queries. All that being said, if users don’t need to collaborate, each one is working on their own data, then you have an easily partitioned domain by user, rather than by separating reads and writes.


  104. joseph Says:

    Hi Udi

    Thanks a lot for this post, which indeed clarifies the CQRS topic.

    You said earlier you would post on Event Sourcing soon, but I didn’t find any related post (apart from the current one). Am I missing something ?

    It would be nice to have such a clear explanation on event sourcing, so.

    Anyway, thanks a lot :)


  105. udidahan Says:

    Thanks for the nudge Joseph :)


  106. DavidZ Says:

    When wil you pubish a book already :) ? I *think my frustration with CQRS and possibly a lot of posts here is that there really isn’t a bible for CQRS so to speak esspecially in relation to DDD+CQRS.

    Please oh please work on a book that will save me a lot of time and headache trying to google cqrs :)


  107. udidahan Says:

    DavidZ,

    If only I had the time :-)


  108. joseph Says:

    Hi Udi

    Another question came to my mind: would you recommend CQRS only for application when performance/scalability is of the uttermost importance or more as a pattern applicable to any application, like some intranet one?

    Having watched some of your talks on infoq I kind of had the feeling CQRS so much reducing the domain to its core that it would end up providing value anywhere, but most likely I’m just being over enthusiastic…

    thanks again
    best


  109. udidahan Says:

    Joseph,

    I wouldn’t say that performance/scalability are the deciding factors towards choosing CQRS – but they do contribute. The primary property of a system that would make it a good fit for CQRS is whether it is collaborative – ergo multiple users/actors working in parallel on a shared set of data.

    It is likely that there are parts of a system that are collaborative, and parts that aren’t. As such, CQRS should only be used for the collaborative parts.


  110. joseph Says:

    Thanks again for this clarification udi, really helpful as usual.

    Mind if someday I translate this article in french and link back to your post ?

    best
    joseph


  111. udidahan Says:

    Joseph,

    That would be great – thanks.


  112. brouce.liu Says:

    hi, udi, I’m very interested in your diagram about CQRS.
    And would you like to let me know what tool to draw this diagram?

    Thanks in advanced.


  113. udidahan Says:

    Brouce,

    I use powerpoint.


  114. Sanket Naik Says:

    Great Post Udi.


  115. Michal Says:

    Hi Udi.

    I have a couple of design questions about applying CQS in non-distributed envirnoment (possible integrations). Ill be very thankfull if You’ll share some experience with me.

    1. Obviously query is synchronous call, but… should we return data in form of DTO or just DataTable or DataSet. Some articles says that DataTable is enough but I have really horrible experience with it (easy to break something by changing columns names, and when project is changed very often -> hell) DTOs gives cenrtalized mappings.

    Ive came to something like query objects (repositories doesnt provide anything in age of ‘big’ orms).

    interface IQueryPerformer
    {
    TResult Perform(IQuery query);
    }

    IntelliSense/Resharper is helping a lot when we type for example:
    List documents = QP.Perform(new …);

    2.By using this approach Ive moved into another issue. Are queries part of service(gets data contained by service) or queries are universal and all lives inside one place?

    Whats Your way to deal with querying data? Somekind of best practice for medium size projects (non high available)

    3.Commands, sent over somekind of bus or command processor. What kind of validations are performed before sending command? Only client side validations(filled field ect)? Or also domain validations(some specific business rules)?

    I would like to perform domain validations inside a handler, but then – how to return results from command?

    For example:
    WebForms/MVC (doesn’t matter)
    Under click handler we are performing some basic validations of fields. If command is valid to send, we are sending.
    Then some commandHandler handles command and starts business rules validation, what we should do if something goes wrong and command cant be processed? Throw exception? But what if we must just return specific result of processing, like ID of new created contract, product, ect?
    We can’t assume that command will success, unless will pull out business rules validations from inside of domain. (and Im not 100% sure about that)

    Kind Regards
    Michal Samociuk


  116. Samuel Says:

    “What if we just serialised the domain entity and put it into a single
    column, and had another column containing the ID? This sounds quite similar to key-value storage that
    is available in the various cloud providers. In which case, would you really need an object-relational
    mapper to persist to this kind of storage?
    You could also pull out an additional property per piece of data where you’d want the “database” to
    enforce uniqueness.
    I’m not suggesting”

    I don’t agree with some of the assumptions you have here, but this one I think is just so plain wrong. So should we drop almost everything that was built in terms of software development and replace it with this nonsense? Since when did data referential integrity become a second level citizen in the system?! I thought that data was way too important. Hell, almost of the software running in the world does just the opposite, implementing proper referential integrity. Also in relation to this?

    “Another thing to understand about the domain model is that it now isn’t used to serve queries. So the
    question is, why do you need to have so many relationships between entities in your domain model?”

    I would love to see such a system. So the system has to process commands and do some validations… where is the data for the validations going to be read from?

    You do have some good ideas in here, but there are a few, that with all respect, are just nonsense.


  117. dgi Says:

    “So, if we’re not returning errors to the client (who is already sending us valid commands), maybe all we need to do on the client when sending a command is to tell the user “thank you, you will receive confirmation via email shortly”. We don’t even need the UI widget showing pending commands.”

    This sentence tells us above CQRS That is only for (about) 5% of applications build upon customer needs.

    At least my experience in building applications for clients indicates those 5%.


  118. udidahan Says:

    dgi,

    Yes, this UI facing application form of CQRS isn’t applicable everywhere – I’ve said as much many times. This is mostly focused on collaborative environments.


  119. Gleb Says:

    Hello.
    First of all, thanks for a great article.
    I have a question – if my system has, let’s say, 60% writes and 40% reads and changes displayed on the screen need to be up to date every time, does it mean that CQRS doesn’t suit me?


  120. Gleb Says:

    Also, I must admit that after reading Evans’ book on DDD I got even more confused than before I read it :) Many people say it’s a great book, and I’m not saying it’s not, but I think I understand about 25% of it if not less.
    Can you recommend some other book on DDD, Jimmy Nilsson’s may be?


  121. udidahan Says:

    Gleb,

    You may be better served with simple CRUD (no extra layers) for some parts of your system, with CQRS coming in to play for more background processes.


  122. Gleb Says:

    I see. What about the book? Any suggestions? May be I should re-read the Evans book?


  123. udidahan Says:

    There’s a new book coming out from Vaughn Vernon called Implementing DDD that will probably help you out quite a bit:

    http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577


  124. Gleb Says:

    Thanks! Will definitely follow book’s reviews


  125. Simon Dowdeswell Says:

    Ive been reading in many places about the use of queues between the web and worker to increase scalability. Im facing a challenge to move an existing system (over 10 years old code) to the Cloud and this pattern appears to be one of the first to adopt for Cloud performance/cost reasons. My question is one you have already faced several times in this blog (but I am not convinced), and i bet its the most common one you face – How does the (asynchronously initiated) worker report information on broken business rules back to the user ? The most common answer in the info ive come across is “by email”. While this works for Amazon, it wont work for the majority of business applications – the application should show them … somehow. Have you come across agreeable mechanisms for this – would you ever build the “Display Widget” you cast out in the blog or do you consider it wrong to do so ?


  126. udidahan Says:

    Simon,

    You can use technologies like SignalR to push notifications back to the browser which initiated the action.

    Cheers,

    Udi


Your comment...



If this is your first time commenting, it may take a while to show up.
I'm working to make that better.

Subscribe here to receive updates on comments.
  
   


Don't miss my best content
 
Locations of visitors to this page

Recommendations

Bryan Wheeler, Director Platform Development at msnbc.com
Udi Dahan is the real deal.

We brought him on site to give our development staff the 5-day “Advanced Distributed System Design” training. The course profoundly changed our understanding and approach to SOA and distributed systems.

Consider some of the evidence: 1. Months later, developers still make allusions to concepts learned in the course nearly every day 2. One of our developers went home and made her husband (a developer at another company) sign up for the course at a subsequent date/venue 3. Based on what we learned, we’ve made constant improvements to our architecture that have helped us to adapt to our ever changing business domain at scale and speed If you have the opportunity to receive the training, you will make a substantial paradigm shift.

If I were to do the whole thing over again, I’d start the week by playing the clip from the Matrix where Morpheus offers Neo the choice between the red and blue pills. Once you make the intellectual leap, you’ll never look at distributed systems the same way.

Beyond the training, we were able to spend some time with Udi discussing issues unique to our business domain. Because Udi is a rare combination of a big picture thinker and a low level doer, he can quickly hone in on various issues and quickly make good (if not startling) recommendations to help solve tough technical issues.” November 11, 2010

Sam Gentile Sam Gentile, Independent WCF & SOA Expert
“Udi, one of the great minds in this area.
A man I respect immensely.”





Ian Robinson Ian Robinson, Principal Consultant at ThoughtWorks
"Your blog and articles have been enormously useful in shaping, testing and refining my own approach to delivering on SOA initiatives over the last few years. Over and against a certain 3-layer-application-architecture-blown-out-to- distributed-proportions school of SOA, your writing, steers a far more valuable course."

Shy Cohen Shy Cohen, Senior Program Manager at Microsoft
“Udi is a world renowned software architect and speaker. I met Udi at a conference that we were both speaking at, and immediately recognized his keen insight and razor-sharp intellect. Our shared passion for SOA and the advancement of its practice launched a discussion that lasted into the small hours of the night.
It was evident through that discussion that Udi is one of the most knowledgeable people in the SOA space. It was also clear why – Udi does not settle for mediocrity, and seeks to fully understand (or define) the logic and principles behind things.
Humble yet uncompromising, Udi is a pleasure to interact with.”

Glenn Block Glenn Block, Senior Program Manager - WCF at Microsoft
“I have known Udi for many years having attended his workshops and having several personal interactions including working with him when we were building our Composite Application Guidance in patterns & practices. What impresses me about Udi is his deep insight into how to address business problems through sound architecture. Backed by many years of building mission critical real world distributed systems it is no wonder that Udi is the best at what he does. When customers have deep issues with their system design, I point them Udi's way.”

Karl Wannenmacher Karl Wannenmacher, Senior Lead Expert at Frequentis AG
“I have been following Udi’s blog and podcasts since 2007. I’m convinced that he is one of the most knowledgeable and experienced people in the field of SOA, EDA and large scale systems.
Udi helped Frequentis to design a major subsystem of a large mission critical system with a nationwide deployment based on NServiceBus. It was impressive to see how he took the initial architecture and turned it upside down leading to a very flexible and scalable yet simple system without knowing the details of the business domain. I highly recommend consulting with Udi when it comes to large scale mission critical systems in any domain.”

Simon Segal Simon Segal, Independent Consultant
“Udi is one of the outstanding software development minds in the world today, his vast insights into Service Oriented Architectures and Smart Clients in particular are indeed a rare commodity. Udi is also an exceptional teacher and can help lead teams to fall into the pit of success. I would recommend Udi to anyone considering some Architecural guidance and support in their next project.”

Ohad Israeli Ohad Israeli, Chief Architect at Hewlett-Packard, Indigo Division
“When you need a man to do the job Udi is your man! No matter if you are facing near deadline deadlock or at the early stages of your development, if you have a problem Udi is the one who will probably be able to solve it, with his large experience at the industry and his widely horizons of thinking , he is always full of just in place great architectural ideas.
I am honored to have Udi as a colleague and a friend (plus having his cell phone on my speed dial).”

Ward Bell Ward Bell, VP Product Development at IdeaBlade
“Everyone will tell you how smart and knowledgable Udi is ... and they are oh-so-right. Let me add that Udi is a smart LISTENER. He's always calibrating what he has to offer with your needs and your experience ... looking for the fit. He has strongly held views ... and the ability to temper them with the nuances of the situation.
I trust Udi to tell me what I need to hear, even if I don't want to hear it, ... in a way that I can hear it. That's a rare skill to go along with his command and intelligence.”

Eli Brin, Program Manager at RISCO Group
“We hired Udi as a SOA specialist for a large scale project. The development is outsourced to India. SOA is a buzzword used almost for anything today. We wanted to understand what SOA really is, and what is the meaning and practice to develop a SOA based system.
We identified Udi as the one that can put some sense and order in our minds. We started with a private customized SOA training for the entire team in Israel. After that I had several focused sessions regarding our architecture and design.
I will summarize it simply (as he is the software simplist): We are very happy to have Udi in our project. It has a great benefit. We feel good and assured with the knowledge and practice he brings. He doesn’t talk over our heads. We assimilated nServicebus as the ESB of the project. I highly recommend you to bring Udi into your project.”

Catherine Hole Catherine Hole, Senior Project Manager at the Norwegian Health Network
“My colleagues and I have spent five interesting days with Udi - diving into the many aspects of SOA. Udi has shown impressive abilities of understanding organizational challenges, and has brought the business perspective into our way of looking at services. He has an excellent understanding of the many layers from business at the top to the technical infrstructure at the bottom. He is a great listener, and manages to simplify challenges in a way that is understandable both for developers and CEOs, and all the specialists in between.”

Yoel Arnon Yoel Arnon, MSMQ Expert
“Udi has a unique, in depth understanding of service oriented architecture and how it should be used in the real world, combined with excellent presentation skills. I think Udi should be a premier choice for a consultant or architect of distributed systems.”

Vadim Mesonzhnik, Development Project Lead at Polycom
“When we were faced with a task of creating a high performance server for a video-tele conferencing domain we decided to opt for a stateless cluster with SQL server approach. In order to confirm our decision we invited Udi.

After carefully listening for 2 hours he said: "With your kind of high availability and performance requirements you don’t want to go with stateless architecture."

One simple sentence saved us from implementing a wrong product and finding that out after years of development. No matter whether our former decisions were confirmed or altered, it gave us great confidence to move forward relying on the experience, industry best-practices and time-proven techniques that Udi shared with us.
It was a distinct pleasure and a unique opportunity to learn from someone who is among the best at what he does.”

Jack Van Hoof Jack Van Hoof, Enterprise Integration Architect at Dutch Railways
“Udi is a respected visionary on SOA and EDA, whose opinion I most of the time (if not always) highly agree with. The nice thing about Udi is that he is able to explain architectural concepts in terms of practical code-level examples.”

Neil Robbins Neil Robbins, Applications Architect at Brit Insurance
“Having followed Udi's blog and other writings for a number of years I attended Udi's two day course on 'Loosely Coupled Messaging with NServiceBus' at SkillsMatter, London.

I would strongly recommend this course to anyone with an interest in how to develop IT systems which provide immediate and future fitness for purpose. An influential and innovative thought leader and practitioner in his field, Udi demonstrates and shares a phenomenally in depth knowledge that proves his position as one of the premier experts in his field globally.

The course has enhanced my knowledge and skills in ways that I am able to immediately apply to provide benefits to my employer. Additionally though I will be able to build upon what I learned in my 2 days with Udi and have no doubt that it will only enhance my future career.

I cannot recommend Udi, and his courses, highly enough.”

Nick Malik Nick Malik, Enterprise Architect at Microsoft Corporation
You are an excellent speaker and trainer, Udi, and I've had the fortunate experience of having attended one of your presentations. I believe that you are a knowledgable and intelligent man.”

Sean Farmar Sean Farmar, Chief Technical Architect at Candidate Manager Ltd
“Udi has provided us with guidance in system architecture and supports our implementation of NServiceBus in our core business application.

He accompanied us in all stages of our development cycle and helped us put vision into real life distributed scalable software. He brought fresh thinking, great in depth of understanding software, and ongoing support that proved as valuable and cost effective.

Udi has the unique ability to analyze the business problem and come up with a simple and elegant solution for the code and the business alike.
With Udi's attention to details, and knowledge we avoided pit falls that would cost us dearly.”

Børge Hansen Børge Hansen, Architect Advisor at Microsoft
“Udi delivered a 5 hour long workshop on SOA for aspiring architects in Norway. While keeping everyone awake and excited Udi gave us some great insights and really delivered on making complex software challenges simple. Truly the software simplist.”

Motty Cohen, SW Manager at KorenTec Technologies
“I know Udi very well from our mutual work at KorenTec. During the analysis and design of a complex, distributed C4I system - where the basic concepts of NServiceBus start to emerge - I gained a lot of "Udi's hours" so I can surely say that he is a professional, skilled architect with fresh ideas and unique perspective for solving complex architecture challenges. His ideas, concepts and parts of the artifacts are the basis of several state-of-the-art C4I systems that I was involved in their architecture design.”

Aaron Jensen Aaron Jensen, VP of Engineering at Eleutian Technology
Awesome. Just awesome.

We’d been meaning to delve into messaging at Eleutian after multiple discussions with and blog posts from Greg Young and Udi Dahan in the past. We weren’t entirely sure where to start, how to start, what tools to use, how to use them, etc. Being able to sit in a room with Udi for an entire week while he described exactly how, why and what he does to tackle a massive enterprise system was invaluable to say the least.

We now have a much better direction and, more importantly, have the confidence we need to start introducing these powerful concepts into production at Eleutian.”

Gad Rosenthal Gad Rosenthal, Department Manager at Retalix
“A thinking person. Brought fresh and valuable ideas that helped us in architecting our product. When recommending a solution he supports it with evidence and detail so you can successfully act based on it. Udi's support "comes on all levels" - As the solution architect through to the detailed class design. Trustworthy!”

Chris Bilson Chris Bilson, Developer at Russell Investment Group
“I had the pleasure of attending a workshop Udi led at the Seattle ALT.NET conference in February 2009. I have been reading Udi's articles and listening to his podcasts for a long time and have always looked to him as a source of advice on software architecture.
When I actually met him and talked to him I was even more impressed. Not only is Udi an extremely likable person, he's got that rare gift of being able to explain complex concepts and ideas in a way that is easy to understand.
All the attendees of the workshop greatly appreciate the time he spent with us and the amazing insights into service oriented architecture he shared with us.”

Alexey Shestialtynov Alexey Shestialtynov, Senior .Net Developer at Candidate Manager
“I met Udi at Candidate Manager where he was brought in part-time as a consultant to help the company make its flagship product more scalable. For me, even after 30 years in software development, working with Udi was a great learning experience. I simply love his fresh ideas and architecture insights.
As we all know it is not enough to be armed with best tools and technologies to be successful in software - there is still human factor involved. When, as it happens, the project got in trouble, management asked Udi to step into a leadership role and bring it back on track. This he did in the span of a month. I can only wish that things had been done this way from the very beginning.
I look forward to working with Udi again in the future.”

Christopher Bennage Christopher Bennage, President at Blue Spire Consulting, Inc.
“My company was hired to be the primary development team for a large scale and highly distributed application. Since these are not necessarily everyday requirements, we wanted to bring in some additional expertise. We chose Udi because of his blogging, podcasting, and speaking. We asked him to to review our architectural strategy as well as the overall viability of project.
I was very impressed, as Udi demonstrated a broad understanding of the sorts of problems we would face. His advice was honest and unbiased and very pragmatic. Whenever I questioned him on particular points, he was able to backup his opinion with real life examples. I was also impressed with his clarity and precision. He was very careful to untangle the meaning of words that might be overloaded or otherwise confusing. While Udi's hourly rate may not be the cheapest, the ROI is undoubtedly a deal. I would highly recommend consulting with Udi.”

Robert Lewkovich, Product / Development Manager at Eggs Overnight
“Udi's advice and consulting were a huge time saver for the project I'm responsible for. The $ spent were well worth it and provided me with a more complete understanding of nServiceBus and most importantly in helping make the correct architectural decisions earlier thereby reducing later, and more expensive, rework.”

Ray Houston Ray Houston, Director of Development at TOPAZ Technologies
“Udi's SOA class made me smart - it was awesome.

The class was very well put together. The materials were clear and concise and Udi did a fantastic job presenting it. It was a good mixture of lecture, coding, and question and answer. I fully expected that I would be taking notes like crazy, but it was so well laid out that the only thing I wrote down the entire course was what I wanted for lunch. Udi provided us with all the lecture materials and everyone has access to all of the samples which are in the nServiceBus trunk.

Now I know why Udi is the "Software Simplist." I was amazed to find that all the code and solutions were indeed very simple. The patterns that Udi presented keep things simple by isolating complexity so that it doesn't creep into your day to day code. The domain code looks the same if it's running in a single process or if it's running in 100 processes.”

Ian Cooper Ian Cooper, Team Lead at Beazley
“Udi is one of the leaders in the .Net development community, one of the truly smart guys who do not just get best architectural practice well enough to educate others but drives innovation. Udi consistently challenges my thinking in ways that make me better at what I do.”

Liron Levy, Team Leader at Rafael
“I've met Udi when I worked as a team leader in Rafael. One of the most senior managers there knew Udi because he was doing superb architecture job in another Rafael project and he recommended bringing him on board to help the project I was leading.
Udi brought with him fresh solutions and invaluable deep architecture insights. He is an authority on SOA (service oriented architecture) and this was a tremendous help in our project.
On the personal level - Udi is a great communicator and can persuade even the most difficult audiences (I was part of such an audience myself..) by bringing sound explanations that draw on his extensive knowledge in the software business. Working with Udi was a great learning experience for me, and I'll be happy to work with him again in the future.”

Adam Dymitruk Adam Dymitruk, Director of IT at Apara Systems
“I met Udi for the first time at DevTeach in Montreal back in early 2007. While Udi is usually involved in SOA subjects, his knowledge spans all of a software development company's concerns. I would not hesitate to recommend Udi for any company that needs excellent leadership, mentoring, problem solving, application of patterns, implementation of methodologies and straight out solution development.
There are very few people in the world that are as dedicated to their craft as Udi is to his. At ALT.NET Seattle, Udi explained many core ideas about SOA. The team that I brought with me found his workshop and other talks the highlight of the event and provided the most value to us and our organization. I am thrilled to have the opportunity to recommend him.”

Eytan Michaeli Eytan Michaeli, CTO Korentec
“Udi was responsible for a major project in the company, and as a chief architect designed a complex multi server C4I system with many innovations and excellent performance.”


Carl Kenne Carl Kenne, .Net Consultant at Dotway AB
“Udi's session "DDD in Enterprise apps" was truly an eye opener. Udi has a great ability to explain complex enterprise designs in a very comprehensive and inspiring way. I've seen several sessions on both DDD and SOA in the past, but Udi puts it in a completly new perspective and makes us understand what it's all really about. If you ever have a chance to see any of Udi's sessions in the future, take it!”

Avi Nehama, R&D Project Manager at Retalix
“Not only that Udi is a briliant software architecture consultant, he also has remarkable abilities to present complex ideas in a simple and concise manner, and...
always with a smile. Udi is indeed a top-league professional!”

Ben Scheirman Ben Scheirman, Lead Developer at CenterPoint Energy
“Udi is one of those rare people who not only deeply understands SOA and domain driven design, but also eloquently conveys that in an easy to grasp way. He is patient, polite, and easy to talk to. I'm extremely glad I came to his workshop on SOA.”

Scott C. Reynolds Scott C. Reynolds, Director of Software Engineering at CBLPath
“Udi is consistently advancing the state of thought in software architecture, service orientation, and domain modeling.
His mastery of the technologies and techniques is second to none, but he pairs that with a singular ability to listen and communicate effectively with all parties, technical and non, to help people arrive at context-appropriate solutions. Every time I have worked with Udi, or attended a talk of his, or just had a conversation with him I have come away from it enriched with new understanding about the ideas discussed.”

Evgeny-Hen Osipow, Head of R&D at PCLine
“Udi has helped PCLine on projects by implementing architectural blueprints demonstrating the value of simple design and code.”

Rhys Campbell Rhys Campbell, Owner at Artemis West
“For many years I have been following the works of Udi. His explanation of often complex design and architectural concepts are so cleanly broken down that even the most junior of architects can begin to understand these concepts. These concepts however tend to typify the "real world" problems we face daily so even the most experienced software expert will find himself in an "Aha!" moment when following Udi teachings.
It was a pleasure to finally meet Udi in Seattle Alt.Net OpenSpaces 2008, where I was pleasantly surprised at how down-to-earth and approachable he was. His depth and breadth of software knowledge also became apparent when discussion with his peers quickly dove deep in to the problems we current face. If given the opportunity to work with or recommend Udi I would quickly take that chance. When I think .Net Architecture, I think Udi.”

Sverre Hundeide Sverre Hundeide, Senior Consultant at Objectware
“Udi had been hired to present the third LEAP master class in Oslo. He is an well known international expert on enterprise software architecture and design, and is the author of the open source messaging framework nServiceBus. The entire class was based on discussion and interaction with the audience, and the only Power Point slide used was the one showing the agenda.
He started out with sketching a naive traditional n-tier application (big ball of mud), and based on suggestions from the audience we explored different solutions which might improve the solution. Whatever suggestions we threw at him, he always had a thoroughly considered answer describing pros and cons with the suggested solution. He obviously has a lot of experience with real world enterprise SOA applications.”

Raphaël Wouters Raphaël Wouters, Owner/Managing Partner at Medinternals
“I attended Udi's excellent course 'Advanced Distributed System Design with SOA and DDD' at Skillsmatter. Few people can truly claim such a high skill and expertise level, present it using a pragmatic, concrete no-nonsense approach and still stay reachable.”

Nimrod Peleg Nimrod Peleg, Lab Engineer at Technion IIT
“One of the best programmers and software engineer I've ever met, creative, knows how to design and implemet, very collaborative and finally - the applications he designed implemeted work for many years without any problems!

Jose Manuel Beas
“When I attended Udi's SOA Workshop, then it suddenly changed my view of what Service Oriented Architectures were all about. Udi explained complex concepts very clearly and created a very productive discussion environment where all the attendees could learn a lot. I strongly recommend hiring Udi.”

Daniel Jin Daniel Jin, Senior Lead Developer at PJM Interconnection
“Udi is one of the top SOA guru in the .NET space. He is always eager to help others by sharing his knowledge and experiences. His blog articles often offer deep insights and is a invaluable resource. I highly recommend him.”

Pasi Taive Pasi Taive, Chief Architect at Tieto
“I attended both of Udi's "UI Composition Key to SOA Success" and "DDD in Enterprise Apps" sessions and they were exceptionally good. I will definitely participate in his sessions again. Udi is a great presenter and has the ability to explain complex issues in a manner that everyone understands.”

Eran Sagi, Software Architect at HP
“So far, I heard about Service Oriented architecture all over. Everyone mentions it – the big buzz word. But, when I actually asked someone for what does it really mean, no one managed to give me a complete satisfied answer. Finally in his excellent course “Advanced Distributed Systems”, I got the answers I was looking for. Udi went over the different motivations (principles) of Services Oriented, explained them well one by one, and showed how each one could be technically addressed using NService bus. In his course, Udi also explain the way of thinking when coming to design a Service Oriented system. What are the questions you need to ask yourself in order to shape your system, place the logic in the right places for best Service Oriented system.

I would recommend this course for any architect or developer who deals with distributed system, but not only. In my work we do not have a real distributed system, but one PC which host both the UI application and the different services inside, all communicating via WCF. I found that many of the architecture principles and motivations of SOA apply for our system as well. Enough that you have SW partitioned into components and most of the principles becomes relevant to you as well. Bottom line – an excellent course recommended to any SW Architect, or any developer dealing with distributed system.”

Consult with Udi

Guest Authored Books
Chapter: Introduction to SOA    Article: The Enterprise Service Bus and Your SOA

97 Things Every Software Architect Should Know



Creative Commons License  © Copyright 2005-2011, Udi Dahan. email@UdiDahan.com    Freely hosted by Weblogs.us