考虑到域事件模式和这篇文章,为什么人们建议每个事务模型保留一个聚合？当一个聚合可以改变另一个聚合的状态时,有很好的情况.即使删除聚合(或改变它的标识)也会导致改变引用它的其他聚合的状态.有人说每个聚合保留一个事务有助于扩展(每个服务器保留一个聚合).但这种思维方式是否打破了DDD的基本特征:技术不可知？
因此,基于上述陈述和您的经验,设计聚合,域事件导致其他聚合更改是不好的,这将导致每个事务有2个或更多聚合(例如:放置新订单时)有100个项目将客户的状态从正常更改为VIP)？
oop domain-driven-design transactions command-query-separation domain-events
我可能对这个问题听起来很愚蠢,但我真的很困惑.创建命令,查询,commandhanlder,queryhandler和存储库以及使用依赖注入来分别根据查询和命令解析查询处理程序和命令处理程序是否有资格作为cqs或cqrs？
或者使用任务并行库为命令和查询处理程序限定为cqs而不是cqs？
或者它是否真的基于用例是否存在协作域的场景 - >多个用户试图访问有限的数据.
design-patterns domain-driven-design command-query-separation cqrs
在使用域驱动设计实现CQRS时,我们将命令接口与查询接口分开.
我的理解是,在域级别,这会显着降低复杂性(特别是在使用事件源时),在域模型中,您的读取模型将与您的写入模型不同.因此,它看起来像是一个单独的域服务,用于读写有界上下文.
在应用程序级别,我们是否需要单独的应用程序服务来进行域的读写分离？
我一直在扮演魔鬼的倡导者.我的想法可能是矫枉过正,要求客户了解其中的差异.但后来我想到一个消费的网络服务如何使用它.通常,它会发出get读取请求和写入发布,这意味着它已经知道了.
我认为清洁应用服务的好处.
domain-driven-design command-query-separation cqrs ddd-service
阅读有关CQS原理的人知道:
CQS声明每个方法应该是执行操作的命令,或者是将数据返回给调用者的查询,而不是两者.
说到ASP.NET MVC动作,CQS是否表明我们不应该有这样的动作？
public PartialView InsertOrder(Order order)
{
OrderService.InsertOrder(order);
return PartialView("OrderDetails", order);
}
此方法正在更改系统的状态并返回当前状态.如果在这里应用CQS,我们应该有两个单独的操作:一个用于插入新订单,一个用于获取系统系统(如果第一个Action成功完成,应该从客户端调用).但是,这使编程变得复杂.
我想知道你对此的看法.
MOSH