Asp.net mvc 在CQRS中创建的聚合根的Guid

Asp.net mvc 在CQRS中创建的聚合根的Guid,asp.net-mvc,domain-driven-design,cqrs,ncqrs,Asp.net Mvc,Domain Driven Design,Cqrs,Ncqrs,查看以下代码: 此处的Guid仅与命令相关。它不是(可能)创建的聚合根的Guid。获取此Guid的最佳实践是什么?如何将任何潜在的验证错误传回将命令放到总线上的代码?例如: _bus.Publish(new CreateClientCommand( Guid.NewGuid(), _clientDetailsReport.ClientName, _clientDetailsReport.Street, _clientDetailsReport.Street

查看以下代码:

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

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

_bus.Commit();   
我知道CQR通常实现最终的一致性。这意味着在实际创建客户机之前可能需要一段时间。一些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");
}

显然,索引页面可能会显示一些包含日记项的网格,用户可能会看到最新创建的日记项(一段时间后的潜力)。如有任何反馈,将不胜感激。谢谢

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

最简单的方法是使用您传递给命令的guid作为实际聚合Id,然后您就有了它,而不必等待它在事件中被传递回来

不确定您的命令为什么有Id,这会使事情变得混乱(是的,一些分布式系统使用它,但这应该是最后的手段)。大多数开发人员将此视为聚合的id

通常,只需创建聚合Id并使用命令发送它。在所有命令创建实体之后

在大多数情况下,命令应该是同步的,这样您就可以抛出错误。使用async命令,您确实应该有成功或失败的回调(并且async应该只在您真正需要的地方使用,因为它会给系统增加很多成本)

你不会进入下一步(如果你需要下一步),直到 A) 它是一个处理最终一致性的系统,很多业务逻辑都是这样做的。例如,等待交换或第三方处理某件事情,那么工作就是在等待该信息。(即该命令创建订单,但订单的处理(例如OrderDetail)可能尚未完成,且订单处于订单处理状态)
B) 在继续之前,您对命令的响应已成功、超时或失败

在弗农·沃恩(Vernon Vaughn)的书《实现域驱动设计》(Implementing Domain Driven Design)中,他们实际上主张将聚合根(gu)id的创建作为一个基础设施问题。我想我可以将聚合根的(gu)id添加到命令中。您认为这可以接受吗?在我的上一个项目中,我们开始使用由基础设施生成的实体ID。它们是弦。但是不管是谁生成ID,它当然必须出现在命令上,这样你就可以找到它来调用你的域逻辑!我希望命令上的GUID(可能对关联读写模型很有用)应该显示在消息信封或命令基础结构中,而不是每个程序员定义的命令上。请提供有关如何关联读写模型的进一步参考。我也很好奇,我一直认为命令总线是单向的,那么在commandBus.Publish(SomeImportantCommand)之后如何获取消息(又称请求/响应模式?);Commit();如需更多问题,请在此处发布新问题,或在DDD邮件列表中发布!我已经提出了一些问题。那里的社区似乎更有帮助,所以(-:。无论如何,谢谢。我就是这么想的。你如何处理“最终一致性”?如果用户在详细信息页的详细信息在读取模型中之前导航到聚合根的详细信息页,会发生什么情况?谢谢。
[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");
}