21

One of the basic tenets of CQRS, as I understand it, is that commands should be behaviour-centric, and have a value in the business or the UL, and not data-centric, ie., CRUD. Instead of focusing on updating a customer, we have commands like CustomerHasMoved. What if you have CRUD screens which are there to correct certain data. For example, we need to change the name of a customer which is misspelled. This doesn't really have much value in the business. Should this just be under the umbrella of an UpdateCustomer command?

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
blockhead
  • 9,655
  • 3
  • 43
  • 69
  • 5
    How is having the correct customer name not have value to the business? Getting the name wrong may mean that goods do not get delivered and there are other scenarios... – Oded Dec 11 '09 at 19:21

3 Answers3

39

I just want to put a comment on this quickly as it popped up.

It is important to note that some objects are actually CRUD and thats ok. I may not really care why a name is changing in my domain where I ship products to people and only need that data to print mailing labels. The trick is in making behavior the default and THEN reverting to a CRUD interface once you are sure you really don't care about the reasons as opposed to vice versa.

Greg

Greg Young
  • 2,513
  • 1
  • 21
  • 13
  • Thanks for your input @Greg. I was googling all over to see what you had to say about these types of CRUD scenarios. I guess the occasional CRUD is still ok to use in a DDD approach, as long as there's absolutely no behavior you want to capture along with it. – Landon Poch Oct 11 '12 at 22:50
  • Upvote. We're spending money here to get functionality (with maintainablility second). Wanna make something perfect and beautiful, be an artist. Get paid like one, too. See my comment to Julien's answer. – FastAl Jul 07 '14 at 14:12
18

Actually, there could be various reasons to update the name of a customer. As you were saying, it could be misspelled or... you could get married and change your name to your husband's.

If you had only an UpdateCustomer command, you would loose the original intent and you would not be able to have different behaviours for each of them. If the name was misselled it could be as simple as updating the database, whereas if your customer got married you might need to notify the marketing departement so tthat they can offer a discount.

In the case that your entity is purely CRUD, that is there is no intent that you can associate with modifying the properties, then it's OK to have an UpdateEntityCommand. You can then transition slowly to something more task based

Julien
  • 7,821
  • 3
  • 23
  • 16
  • 1
    Exactly, so what is one to do? Create a command for every single possible scenario? – blockhead Dec 30 '09 at 17:12
  • 8
    Yes, or at least for each scenario you want to handle. In my example, you would start with CorrectMisspelledCustomerName then later, if you need to, you'll add a MakeCustomerMarried command. CQRS is about behaviour, not about updating data. Therefore you should not have generic commands for updating stuff in your system – Julien Dec 31 '09 at 08:29
  • What if I had a big screen with all fields for my customer. Would I fire off several commands to handle that, or somehow come up with some kind of "behaviour" for that. Perhaps I should just never show all the fields. – blockhead Dec 31 '09 at 13:41
  • 3
    you should probably not show all the fields in an editable way at once, but have a "task based" UI. I.E. only show the fields after the user choosed the action he intent to perform – Julien Jan 04 '10 at 20:22
  • 2
    I second Julien's answer. Task based UI is definitely what CQRS pushing towards. Don't be too caught up having screens for every single tasks. The big screen with all your customer fields may still exist, for e.g Call Center people wants to be able to see all fields in one quick glace. But this view should be read only. All updates can be context specific (mark as read, upgrade, correct name, etc). – ronaldwidha Mar 13 '10 at 07:04
  • @blockhead It might be a good idea to create abstract `ChangeCustomerAddressCommand` and derive more specific commands from it like `CustomerHasMovedCommand` if derived commands doesn't conflict with each other. – Arnis Lapsa Mar 29 '10 at 20:42
  • Any reason why one can't have a more generic command to change the customer address, with the intent as an attribute of that command (perhaps as an enum)? – nilskp Nov 13 '11 at 18:28
  • So if one has an entity which has a lot of data fields, one would have a CorrectXXXCommand for each field? This seems a bit overkill... – Stephen Drew May 12 '14 at 09:41
  • If your entity is purely CRUD, that is there is no intent that you can associate with modifying the properties then there's no need to have specific commands for each field. You could have an UpdateEntityCommand. – Julien May 14 '14 at 15:26
  • 1
    If it's faster or better for this user to be able to edit all fields at one on the display (which sometimes it really is), the software has to deal with it, or it sucks, plain and simple. You can fake it behind the scenes if you are religious about CQRS (but most of the time this is throwing money out the window, see Grey Young's answer). Bottom line is, if the business needs efficiency and the system can't provide it, something's wrong with the system, not the concept of they way the UI is designed (which can also be right or wrong, but 'all updatable' fields just isn't blanket wrong). – FastAl Jul 07 '14 at 14:11
0

CustomerHasMoved is the event that is fired after you have updated the customers location. This event updates the read databases/cache databases. The command from the gui should be MoveCustomer or something like that. I think I would put the update of the customer name in a command like UpdateCustomer.

Fossmo
  • 2,862
  • 4
  • 25
  • 47