在CQRS中创建的聚合根的Guid

Question

从这里看这段代码:

[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;
    }
}

此处的Guid仅与命令相关。它不是(可能)创建的聚合根的Guid。获得此Guid的最佳实践是什么?如何将任何潜在的验证错误传达给在总线上放置命令的代码?例如:

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

我理解CQRS通常实现最终一致性。这意味着在实际创建客户机之前可能需要一段时间。一些MVC/CQRS代码使用这种方法:

[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");
}

显然，索引页可能会显示一些包含DiaryItems的网格，用户可能能够看到最近创建的DiaryItem(可能要过一段时间)。任何反馈将非常感激。谢谢。

Answer 1

您是否在询问命令本身的ID与它可能创建的实体的ID之间的区别?前者通常是一个基础设施问题，存在于消息信封之类的东西上，隐藏在RPC协议中，或类似的东西中。后者将是你的领域的一部分。(尽管在许多情况下，最好将实体的ID也视为基础设施问题，因为在持久化模型中选择它可能是为了方便。)

Answer 2

最简单的方法是使用您传递给命令的guid作为实际的聚合Id，然后您就可以使用它，而不必等待它在事件

Answer 3

不知道为什么你的命令有一个id，它混淆了事情(是的，一些分布式系统使用这个，但它应该是最后的手段)。大多数开发人员会将其视为聚合的id。

一般只需创建聚合Id并将其与命令一起发送。在所有命令创建实体之后。

在大多数情况下，

命令应该是同步的，这样你就可以把错误扔回去。使用async命令，你真的应该有一个成功或失败的回调(async应该只在你真正需要的地方使用，它会给系统增加很多成本)。

你不会移动到下一步(如果你需要下一步)，直到A)它是一个处理最终一致性的系统，很多业务逻辑都是这样做的。例如，等待交换或第三方处理某些事情，然后工作正在等待该信息。(即命令创建了一个订单，但订单的处理(例如OrderDetail)可能还没有，订单的状态为Order processing)B)在继续之前对命令有成功、超时或失败的响应。