Guid of created aggregate root in CQRS

Question

Looking at this code from here:

[Serializable]
public class CreateClientCommand : Command
{
    public string ClientName { get; private set; }
    public string Street { get; private set; }
    public string StreetNumber { get; private set; }
    public string PostalCode { get; private set; }
    public string City { get; private set; }
    public string PhoneNumber { get; private set; }

    public CreateClientCommand(Guid id, string clientName, string street, string streetNumber, string postalCode, string city, string phoneNumber) : base(id)
    {
        ClientName = clientName;
        Street = street;
        StreetNumber = streetNumber;
        PostalCode = postalCode;
        City = city;
        PhoneNumber = phoneNumber;
    }
}

The Guid here is just relevant for the command. It is not the Guid of the (potentially) created aggregate root. What is the best practice to obtain this Guid and how are any potential validation errors communicated back to the the code that puts a command on the bus? For example like this:

_bus.Publish(new CreateClientCommand(
     Guid.NewGuid(),
     _clientDetailsReport.ClientName,
     _clientDetailsReport.Street,
     _clientDetailsReport.StreetNumber,
     _clientDetailsReport.PostalCode,
     _clientDetailsReport.City,
     _clientDetailsView.PhoneNumber));

_bus.Commit();

I understand that CQRS usually implements eventual consistency. This means that it might take a while before the client is actually created. Some MVC/CQRS code uses this approach:

[HttpPost]
public ActionResult Add(DiaryItemDto item)
{
    ServiceLocator.CommandBus.Send(new CreateItemCommand(Guid.NewGuid(),item.Title,item.Description,-1,item.From,item.To));

    return RedirectToAction("Index");
}

Obviously, the index page might show some grid containing the DiaryItems and the user might be able to see the latest created DiaryItem (potentiality after a while). Any feedback would be very much appreciated. Thanks.

score 2 · Accepted Answer · answered Jun 24 '14 at 14:19

2

Are you asking about the distinction between an ID for the command itself, versus the ID of the entity it might create? The former would typically be an infrastructure concern, found on something like a message envelope, buried in a RPC protocol, or the like. The latter would be part of your domain. (Though in many cases, it's nice to treat the ID of an entity as an infrastructure concern as well, since you might choose it for convenience in your persistence model.)

answered Jun 24 '14 at 14:19

Sebastian Good

6,310
2
33
57

In Vernon Vaughn's book: Implementing Domain-Driven Design they actually argue to make the creation of the aggregate root's (gu)id an infrastructure concern. I guess I could add the aggregate root's (gu)id to the command. Is this acceptable in your opinion? – cs0815 Jun 24 '14 at 14:26
1

In my last project, we moved to having entity IDs generated by infrastructure. They were strings. But no matter who generates the ID, it of course has to appear on the command so you can find it to call your domain logic on it! I'd The GUID on your command, useful perhaps for correlating write and read models, should show up in a message envelope or in the command infrastructure, not on every programmer-defined command. – Sebastian Good Jun 24 '14 at 18:09
Can you please provide further references on how to correlate the read and write model. I am also curious, I always thought the command bus is unidirectional, so how do you obtain message (aka request/response pattern?) after commandBus.Publish(SomeImportantCommand); commandBus.Commit(); – cs0815 Jun 24 '14 at 19:12
For more questions, please post a new question here on SO, or post to one of the DDD mailing lists! – Sebastian Good Jun 24 '14 at 21:04
I have already raised some questions I have there. The community there seems to be more helpful then SO (-:. Thanks anyway. – cs0815 Jun 25 '14 at 07:42

score 2 · Answer 2 · answered Jun 24 '14 at 14:30

2

The easiest way to do this is to use the guid that you pass on the command as the actual aggregate Id and then you have it to hand and don't have to wait for it to be communicated back down on an event

answered Jun 24 '14 at 14:30

SammoSampson

245
3
8

1

Thanks that's what I thought. How do you deal with 'eventual consistency'? What happens if the user navigates to the aggregate root's details page before the details page's details are in the read model? Thanks. – cs0815 Jun 24 '14 at 15:11

score 1 · Answer 3 · answered Jun 26 '14 at 23:36

Not sure why your command has an id it confuses things ( Yes some distributed systems use this but it should be a last resort). Most developers would see this as the id of the aggregate .

Generally just create the aggregate Id and send it with the command . After all the command is creating the Entity ..

Commands should in most cases be sync so you can throw errors back . With async commands you really should have a call back for success or failure ( and async should only be used where you really have the need it adds a lot of cost to the system ) .

You don't move to the next step ( if you need a next step ) until either A) Its a system that deals with eventual consistency, a lot of business logic does do this. eg waiting for the exchange or a 3rd party to process something , then the work is waiting for that information . ( Ie the command creates an Order but the processing of the order eg OrderDetail may not be there yet and the order has a state of Order Processing) B) You have success , timeout or failure response to command before continuing .

Guid of created aggregate root in CQRS

3 Answers3