Comments on: CQRS isn’t the answer – it’s just one of the questions http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/ Enterprise Development Expert & SOA Specialist Sat, 11 Feb 2012 15:16:10 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: udidahan http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37462 udidahan Tue, 21 Sep 2010 19:21:33 +0000 http://www.udidahan.com/?p=1278#comment-37462 Maninder, CQRS is applicable to data and behavior together - not to data separately. Maninder,

CQRS is applicable to data and behavior together – not to data separately.

]]> By: Maninder Batth http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37460 Maninder Batth Tue, 21 Sep 2010 15:16:56 +0000 http://www.udidahan.com/?p=1278#comment-37460 Udi, To what kind of data is CQRS applicable? Surely, with organization having petabytes of information, it is not feasible that every function subscribes to "interesting" events and store a local copy. For example take "reference data". typically there is a logical function called reference data services, which provide access to clean and latest reference data. Should reference data systems start publishing their changes and every system interested in reference data maintain a copy of events? Secondly, CQRS also seems to imply additional CRUD capabilities for every entity that a function is interested in. If function A is interested in events X, Y, Z, but the responsibility of function A is to analyze and present some information, one way to accomplish is that function A pulls the information about X Y and Z from their respective sources, but in CQRS model, function A will subscribe to these events and now needs some functionality to "do something" once it gets X Y and Z. Perhaps update logic, perhaps insert.. And additional it has logic to retrieve X Y and Z from its local db when it wants to analyze them. It doesnt seem bad with few entities, but as subscription interest grows, so will this extra logic. Udi,
To what kind of data is CQRS applicable? Surely, with organization having petabytes of information, it is not feasible that every function subscribes to “interesting” events and store a local copy.
For example take “reference data”. typically there is a logical function called reference data services, which provide access to clean and latest reference data. Should reference data systems start publishing their changes and every system interested in reference data maintain a copy of events?
Secondly, CQRS also seems to imply additional CRUD capabilities for every entity that a function is interested in. If function A is interested in events X, Y, Z, but the responsibility of function A is to analyze and present some information, one way to accomplish is that function A pulls the information about X Y and Z from their respective sources, but in CQRS model, function A will subscribe to these events and now needs some functionality to “do something” once it gets X Y and Z. Perhaps update logic, perhaps insert.. And additional it has logic to retrieve X Y and Z from its local db when it wants to analyze them.
It doesnt seem bad with few entities, but as subscription interest grows, so will this extra logic.

]]> By: Matt S. http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37325 Matt S. Tue, 06 Jul 2010 13:10:47 +0000 http://www.udidahan.com/?p=1278#comment-37325 Udi, That last bit REALLY helped! Making special cases for private data to directly query the live data makes complete sense. So does letting users know the time the current data was retrieved in a collaborative environment. Thanks again for clearing it up. Udi,

That last bit REALLY helped! Making special cases for private data to directly query the live data makes complete sense. So does letting users know the time the current data was retrieved in a collaborative environment.

Thanks again for clearing it up.

]]> By: udidahan http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37314 udidahan Thu, 01 Jul 2010 05:29:57 +0000 http://www.udidahan.com/?p=1278#comment-37314 Matt, Part of CQRS is explicitly telling users how stale the data they're looking at is: "Account information as of today at 12:00pm". Keep in mind that if you have a user who is aggressively modifying some data, it's likely that that data is private at that point in time - possibly requiring the user to perform a kind of "publish" operation to make it visible to other users. When the user is working on private data, there is no collaboration going on, therefore no need for CQRS. Hope that helps. Matt,

Part of CQRS is explicitly telling users how stale the data they’re looking at is: “Account information as of today at 12:00pm”.

Keep in mind that if you have a user who is aggressively modifying some data, it’s likely that that data is private at that point in time – possibly requiring the user to perform a kind of “publish” operation to make it visible to other users.

When the user is working on private data, there is no collaboration going on, therefore no need for CQRS.

Hope that helps.

]]> By: Matt S. http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37308 Matt S. Tue, 29 Jun 2010 18:28:00 +0000 http://www.udidahan.com/?p=1278#comment-37308 I'm still having a hard time wrapping my brain around this technique when it comes to my users' (primarily website users) need for instant gratification. They expect to see their recent edits applied. I previously commented about a system that allows its users to update their account information. If they make such an edit, realize they forgot something, then go back to the edit view/page to change what they forgot, they may still see the old information (prior to their edit moments ago). I would really rather not have to code for an ambitious user that constantly checks to make sure the change they just made is taking, and reissuing it if not (i.e. view edit page, submit change, view edit page and still see old data, submit change again, view edit page, submit change again, ...). Am I missing something or are we only talking about the customer service representative example I keep seeing replayed? I’m still having a hard time wrapping my brain around this technique when it comes to my users’ (primarily website users) need for instant gratification.

They expect to see their recent edits applied. I previously commented about a system that allows its users to update their account information. If they make such an edit, realize they forgot something, then go back to the edit view/page to change what they forgot, they may still see the old information (prior to their edit moments ago).

I would really rather not have to code for an ambitious user that constantly checks to make sure the change they just made is taking, and reissuing it if not (i.e. view edit page, submit change, view edit page and still see old data, submit change again, view edit page, submit change again, …).

Am I missing something or are we only talking about the customer service representative example I keep seeing replayed?

]]> By: Eben http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37257 Eben Mon, 24 May 2010 06:44:06 +0000 http://www.udidahan.com/?p=1278#comment-37257 Nice post! I do think, however, that as time goes by certain techniques *can* be used in *all* situations but it may be that in some applications it is overkill :) --- as would be the case in a 'small application' Anyway, any application that is going to be going anywhere (in terms of longevity and complexity) should be looking at CQRS as best practise. Eventual consistency, OTOH, is another matter. I would not *not* consider it as best practice. Eben Nice post!

I do think, however, that as time goes by certain techniques *can* be used in *all* situations but it may be that in some applications it is overkill :) — as would be the case in a ’small application’

Anyway, any application that is going to be going anywhere (in terms of longevity and complexity) should be looking at CQRS as best practise.

Eventual consistency, OTOH, is another matter. I would not *not* consider it as best practice.

Eben

]]> By: Kevin Jordan http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37253 Kevin Jordan Mon, 17 May 2010 15:28:31 +0000 http://www.udidahan.com/?p=1278#comment-37253 "CQRS is actually in danger of reaching “best practice” status at which point in time people will apply it indiscriminately with truly terrible results." One does get this impression by the amount of material out there on the subject. It's easy to see why this is the case. Here are the driving forces from your previous blog entry: "Collaboration refers to circumstances under which multiple actors will be using/modifying the same set of data" "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." The problem is an argument could be made that both of these driving forces were true for all of the applications (client side and web) I have built over the last 10 years. I haven't implemented CQRS or looked at a sample app as of yet, just doing alot of reading and trying to wrap my head around when to apply it. Great articles.... Cheers “CQRS is actually in danger of reaching “best practice” status at which point in time people will apply it indiscriminately with truly terrible results.”

One does get this impression by the amount of material out there on the subject. It’s easy to see why this is the case. Here are the driving forces from your previous blog entry:

“Collaboration refers to circumstances under which multiple actors will be using/modifying the same set of data”

“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.”

The problem is an argument could be made that both of these driving forces were true for all of the applications (client side and web) I have built over the last 10 years.

I haven’t implemented CQRS or looked at a sample app as of yet, just doing alot of reading and trying to wrap my head around when to apply it. Great articles….

Cheers

]]> By: Adam http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37250 Adam Fri, 14 May 2010 14:58:22 +0000 http://www.udidahan.com/?p=1278#comment-37250 Great article. Although you are explicitly talking about CQRS I feel like this applies on a much broader scope of "right tool for the job." Too many times people find a hammer that they like and decide to use that hammer for everything, even if they really need a screwdriver, or jigsaw. Great article. Although you are explicitly talking about CQRS I feel like this applies on a much broader scope of “right tool for the job.” Too many times people find a hammer that they like and decide to use that hammer for everything, even if they really need a screwdriver, or jigsaw.

]]> By: Charlie Barker http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37249 Charlie Barker Fri, 14 May 2010 00:22:54 +0000 http://www.udidahan.com/?p=1278#comment-37249 I like this rule of thumb it is a good sanity check. I find that once I have a sufficient understanding of the business problem building a solution becomes straightforward. The tricky part is building the understanding. In any given scenario there are many factorss that will affect your ability to build your understanding. I find the larger and more complex problems take many sessions starting at the high level and working down to the detail. The toughest tasks are where a business is innovating so there are no experts to ask. In this scenario I accept early on that there may be significant direction changes along the way and thus im prepared to scrap or redesign as learning dictates. I like this rule of thumb it is a good sanity check. I find that once I have a sufficient understanding of the business problem building a solution becomes straightforward. The tricky part is building the understanding. In any given scenario there are many factorss that will affect your ability to build your understanding. I find the larger and more complex problems take many sessions starting at the high level and working down to the detail.
The toughest tasks are where a business is innovating so there are no experts to ask. In this scenario I accept early on that there may be significant direction changes along the way and thus im prepared to scrap or redesign as learning dictates.

]]> By: ste http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37248 ste Thu, 13 May 2010 18:17:06 +0000 http://www.udidahan.com/?p=1278#comment-37248 How is "true single-user-only-thing" defined? Does it mean, that only a single user views or edits certain data at a time but there could be some kind of process which passes the data from one user to another. Or does it mean that certain data is owned by a single user and only used by this user (like a private document)? How is “true single-user-only-thing” defined?
Does it mean, that only a single user views or edits certain data at a time but there could be some kind of process which passes the data from one user to another. Or does it mean that certain data is owned by a single user and only used by this user (like a private document)?

]]> By: Tarek Nabil http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37246 Tarek Nabil Tue, 11 May 2010 08:18:17 +0000 http://www.udidahan.com/?p=1278#comment-37246 Josh, What you're describing is some times referred to as a "Pessimistic Offline Lock". Although it is suitable for certain situations, it has its limitations, especially in web applications, where users can abandon their sessions and the offline lock would only be released on timeout (whether of the session or the lock). If you try to fix that by reducing the timeout period of the lock then you risk having the locks timeout while the users are still editing the data. Josh,

What you’re describing is some times referred to as a “Pessimistic Offline Lock”. Although it is suitable for certain situations, it has its limitations, especially in web applications, where users can abandon their sessions and the offline lock would only be released on timeout (whether of the session or the lock).

If you try to fix that by reducing the timeout period of the lock then you risk having the locks timeout while the users are still editing the data.

]]> By: Frank Quednau http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37245 Frank Quednau Mon, 10 May 2010 21:28:01 +0000 http://www.udidahan.com/?p=1278#comment-37245 Reminds me of the fact that there is a formula to calculate an arbitrary digit being at the nth position of the number Pi without calculating the preceding digits - however, it only works with the binary number system. (http://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula) Reminds me of the fact that there is a formula to calculate an arbitrary digit being at the nth position of the number Pi without calculating the preceding digits – however, it only works with the binary number system. (http://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula)

]]> By: Alex Simkin http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37244 Alex Simkin Mon, 10 May 2010 13:25:33 +0000 http://www.udidahan.com/?p=1278#comment-37244 Base 10 is not a ubiquitous best practice. In fact it is. 10 (one followed by zero) is ALWAYS base in any positional numbering system. So you should have been using word "ten" not symbol 10. Base 10 is not a ubiquitous best practice.

In fact it is. 10 (one followed by zero) is ALWAYS base in any positional numbering system.

So you should have been using word “ten” not symbol 10.

]]> By: Josh Schwartzberg http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37243 Josh Schwartzberg Mon, 10 May 2010 03:48:08 +0000 http://www.udidahan.com/?p=1278#comment-37243 Tarek, More explicitly, if you do not allow the second user to click the "begin editing" button for an entity, they would never accidently do some work and find out that all is lost when they go to hit save because someone did it first. This is much like the exclusive check-out mode that many source control systems have. Again, it's not ideal behavior but it could be a valid solution for smaller systems. Tarek,

More explicitly, if you do not allow the second user to click the “begin editing” button for an entity, they would never accidently do some work and find out that all is lost when they go to hit save because someone did it first. This is much like the exclusive check-out mode that many source control systems have. Again, it’s not ideal behavior but it could be a valid solution for smaller systems.

]]> By: Chris Nicola http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37242 Chris Nicola Sun, 09 May 2010 17:30:22 +0000 http://www.udidahan.com/?p=1278#comment-37242 Udi, this is all very interesting and as a fairly pragmatic software developer I'd never assume CQRS is a silver bullet solution for anything. However while in this post you have given yet another reason for why and when we should use CQRS I've felt you have not really supported your assertion that there are situations when not to use it. Could you give at least one concrete example of a situation where there would be notable drawbacks to using CQRS as a solution and perhaps illustrate what those drawbacks are? Udi, this is all very interesting and as a fairly pragmatic software developer I’d never assume CQRS is a silver bullet solution for anything. However while in this post you have given yet another reason for why and when we should use CQRS I’ve felt you have not really supported your assertion that there are situations when not to use it.

Could you give at least one concrete example of a situation where there would be notable drawbacks to using CQRS as a solution and perhaps illustrate what those drawbacks are?

]]> By: Tarek http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37241 Tarek Sun, 09 May 2010 09:37:13 +0000 http://www.udidahan.com/?p=1278#comment-37241 Josh, "Pessimistic Locking" is interpreted in different ways. Merely locking the record while you're updating it does not really solve the problem if the other concurrent request will be served right after you release the lock. The other user has already made a decision based on data he had on the screen which is now stale. A common solution to this problem is to read the version field of the record, store it on the client side, and then submit it along with the changes. So, if you read a record, spend 10 minutes updating it and during those 10 minutes someone else changes it then you'll get an error. This happened to me the other day and I ended up losing 10 minutes of work and cursing the application :( Of course, there is the solution of merging the changes but again that can only be done based on deep understanding of the business requirements. I'm not saying CQRS is necessarily the solution but some solution is definitely required for this problem. Josh,

“Pessimistic Locking” is interpreted in different ways. Merely locking the record while you’re updating it does not really solve the problem if the other concurrent request will be served right after you release the lock. The other user has already made a decision based on data he had on the screen which is now stale.

A common solution to this problem is to read the version field of the record, store it on the client side, and then submit it along with the changes. So, if you read a record, spend 10 minutes updating it and during those 10 minutes someone else changes it then you’ll get an error. This happened to me the other day and I ended up losing 10 minutes of work and cursing the application :(

Of course, there is the solution of merging the changes but again that can only be done based on deep understanding of the business requirements.

I’m not saying CQRS is necessarily the solution but some solution is definitely required for this problem.

]]> By: James Pelletier http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37239 James Pelletier Sun, 09 May 2010 07:08:31 +0000 http://www.udidahan.com/?p=1278#comment-37239 So often when I start asking why I get ushered out the door... I'm having trouble making people see these are important questions. So often when I start asking why I get ushered out the door… I’m having trouble making people see these are important questions.

]]> By: Diogo Mafra http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37238 Diogo Mafra Fri, 07 May 2010 22:24:02 +0000 http://www.udidahan.com/?p=1278#comment-37238 Great post!! I would like to see more people asking the real question, the WHY behind the problem. And also realizing that, there is not only one solution for everything. By asking the why, we gain a better view of the problem and, sometimes, it helps the user to realize what he really need. Great post!! I would like to see more people asking the real question, the WHY behind the problem. And also realizing that, there is not only one solution for everything.

By asking the why, we gain a better view of the problem and, sometimes, it helps the user to realize what he really need.

]]> By: Josh Schwartzberg http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37236 Josh Schwartzberg Fri, 07 May 2010 15:00:19 +0000 http://www.udidahan.com/?p=1278#comment-37236 Great post. So basically 2 or more users working on the same data warrants CQRS :)? Before jumping right into CQRS and eventual consitency, Pessimistic Locking with CRUD can work well in small (5-10 user) collaborative data systems; preventing the user from ever attempting to alter stale data at the business cost of "waiting in line" to do so. Obviously this business cost grows exponentially the larger the system gets, but if you are fairly sure it's not going to happen it should be evaluated as a solution. Great post. So basically 2 or more users working on the same data warrants CQRS :) ? Before jumping right into CQRS and eventual consitency, Pessimistic Locking with CRUD can work well in small (5-10 user) collaborative data systems; preventing the user from ever attempting to alter stale data at the business cost of “waiting in line” to do so. Obviously this business cost grows exponentially the larger the system gets, but if you are fairly sure it’s not going to happen it should be evaluated as a solution.

]]> By: PMBauer http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37235 PMBauer Fri, 07 May 2010 13:35:57 +0000 http://www.udidahan.com/?p=1278#comment-37235 @Remco Ross Nope, in base 2, 1+1 = 10. :D @Remco Ross
Nope, in base 2, 1+1 = 10.
:D

]]> By: Nitpicker http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37234 Nitpicker Fri, 07 May 2010 12:45:52 +0000 http://www.udidahan.com/?p=1278#comment-37234 @Remco Ros: 1 + 1 = 10 in base 2! @Remco Ros:
1 + 1 = 10 in base 2!

]]> By: junior programmer http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37233 junior programmer Fri, 07 May 2010 12:00:36 +0000 http://www.udidahan.com/?p=1278#comment-37233 please don't talk vague! we need concrete examples. please don’t talk vague! we need concrete examples.

]]> By: Remco Ros http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37232 Remco Ros Fri, 07 May 2010 11:47:50 +0000 http://www.udidahan.com/?p=1278#comment-37232 Really nice post Udi. Funny side note: No matter what numeric base you take, 1 + 1 will always be 2 ;-) Really nice post Udi.

Funny side note: No matter what numeric base you take, 1 + 1 will always be 2 ;-)

]]> By: Rinat Abdullin http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/comment-page-1/#comment-37231 Rinat Abdullin Fri, 07 May 2010 11:27:56 +0000 http://www.udidahan.com/?p=1278#comment-37231 Nice article, I really liked the concise rule of collaboration in CQRS - straight to the point. Potential typo: "After understanding all that and you find a true single-user-only-thing," BTW, Occam's razor applies to the base of 13 theory - it was just a joke, as admitted by Adams)) Nice article, I really liked the concise rule of collaboration in CQRS – straight to the point.

Potential typo: “After understanding all that and you find a true single-user-only-thing,”

BTW, Occam’s razor applies to the base of 13 theory – it was just a joke, as admitted by Adams))

]]>