Feb 02 2010
Idea: a lightweight CQRS utility library
Yesterday I started implementing some utilities to speed up development inside a CQRS architecture. In this first attempt I’m trying to reduce the friction that exists between the “typical style” of client side development and sending commands back to the server. The core idea is that there’s no need for code inside to UI layer that creates the commands; they should be inferred from state changes that happen through databinding. This allows for increased development time on task based as well as more regular UI’s. This code snippet gives you an idea of the concept.
public class PersonDto : ClientSideRepositoryItem
{
public Guid Id { get; private set; }[OnValueChanged(typeof(ChangePersonsMaritalStatusCommand))]
public int MaritalStatus { get; set; }
}
public class ChangePersonsMaritalStatusCommand: ICommand
{
public Guid Id { get; private set; }
public int MaritalStatus { get; set; }
}
The ClientSideRepositoryItems build themselves a list of commands that can be flushed to the server in order to apply them. Autocreating the commands and setting its properties will involve some conventions. And I will need to add support for collections, value based command selection perhaps and some neat algorithms to keep the command list sane.
This is just an idea at this stage; I’m not sure it will work. Send me feedback!
How would you handle it for complex property like an Address?
public class PersonDto : ClientSideRepositoryItem
{
[OnValueChanged(typeof(ChangePersonAddressCommand))]
public AddressDto Address { get; set; }
}
public class AddressDto
{
public string Street { get; set; }
public string City { get; set; }
public string Province { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
}
I will need to provide several options for composition. The first is your example; where AddressDto is not a ClientSideRepositoryItem and does not have it’s own identifier. (The ChangePersonAddressCommand will need to have a PersonId in order to be valid) And second the case of composed ClientSideRepositoryItems which do have their own key and their own command definitions. The latter is easy since it’s just a recursive application of a simple-type approach, the first does deal with complex objects and might be difficult to implement.
[...] SuppleDesign - Marc Vangrieken’s blog » Idea: a lightweight CQRS utility library viss.be/2010/02/02/idea-a-lightweight-cqrs-utility-library – view page – cached Yesterday I started implementing some utilities to speed up development inside a CQRS architecture. In this first attempt I’m trying to reduce the friction that exists between the “typical style” of client side development and sending commands back to the server. The core idea is that there’s no need for code inside to UI layer that creates the commands; they should be inferred from state… Read moreYesterday I started implementing some utilities to speed up development inside a CQRS architecture. In this first attempt I’m trying to reduce the friction that exists between the “typical style” of client side development and sending commands back to the server. The core idea is that there’s no need for code inside to UI layer that creates the commands; they should be inferred from state changes that happen through databinding. This allows for increased development time on task based as well as more regular UI’s. This code snippet gives you an idea of the concept. View page [...]
This is so wrong on so many levels that I won’t even try to explain (but I’m gonna anyway). Although in essence you capture intent, try binding to your viewmodel and have a viewmodel on a per command basis (if possible - guess that ‘ll be easy for your crud-like example), use command validation on the client to provide validation feedback to your view. This will help you focus on what commands really are.
What ticks me off is the fact that you still have the words DTO up there, that on the client you try to make an explicit command, which should have been discussed with your domain expert, into something implicit like slapping it onto a field (Do you really have an explicit command to change a “person’s” marital status? What kind of value does that have to your business? Don’t get me wrong, I’m asking, not saying this example is not legit.) I don’t want to focus too much on the example because I don’t know how real it is.
The fact that you want to batch commands is actually very good. But make sure that they actually are commands, not mere state changes nobody is really interested in (they are when they start looking like events of what happened on the client that need to be stored on the server without any logic to them - when this is the case then try to bundle them up into one big fat command or start wondering if you should be applying CQRS to this portion of your application).
Hi Yves.
Thanks for the feedback.
Do you agree on the premise that it’s useful in most cases to have commands, sent from the ui to the server (within the same service)? As opposed to a “save this stuff” call. I hardly find any applications anymore that have pure data-entry properties.
In this example, which is too small, ChangePersonsMaritalStatus is a significant occurence. (eg. when this command comes in, we want to transform it to a PersonMaritalStatusChanged message, publish it and have another service send him/her a present :)).
Note that the explicitness/visibility is still there, commands and commandhandlers (whatever the latter are; IHandleChangePersonsMaritalStatus) are still in server-side code. In the end, only the way of kicking it off that differs.
Please also note that I think UI development should be as straightforward as possible. This approach does make somewhat less explicit calls. But on the flipside; i’ve seen “viewmodel per command” become tedious and blurry, with all the eventaggregators of the world.
Marc,
Ofcourse commands are more valuable than the “old” way of doing things. So, I’m not trying to bash here. One thing to consider though, is that you can easily have one command “ModifyXXX” which produces “RenamedXXXEvent”, “ChangedMaritalStatusEvent”, …
Although this could be seen as a bit of a fallacy, it does capture the general purpose intent, and produces the sequence of events you are interested in.
On the teadiousness of creating a UI: commands will not be the part were you’ll spend most of your time developing (subjective experience,I admit).
Bottom line is that I would go for a “ModifyXXXCommand” on the client to communicate intent, which will save you the pain of supporting all those mini commands on the client (when actually you only want them as events on the server). Remember that commands tell the domain what to do, the domain in turn tells what happened inside of it! There is no prescriptive 1 to 1 mapping between them.