Jos*_*orp 7 domain-driven-design transactions aggregate aggregateroot cqrs
在DDD中,Aggregate应代表事务边界.需要涉及多个聚合的交易通常表明应该改进模型,或者应该审查交易要求,或者两者兼而有之.
这是指每个聚合根INSTANCE还是每个聚合的事务边界？
假设我有一个名为"Node"的聚合根,在每个"Node"中我都有一个"Fields(Value objects)"的集合.每个"Field"都是Type,可以是Type"Node".在我的情况下,如果它是类型"节点",我将Id存储到"节点"聚合根.
Node (AggregateRootID 1)
---> Field1 : String (John)
---> Field2 : String (Doe)
---> Field3 : Node (AggregateRootID 2)
Node (AggregateRootID 2)
--> Field1 : String (Jane)
--> Field2 : String (Doe)
如果我有一个更新两个AggregateRoots实例的事务,那有效吗？
或者它是否意味着如果我有"节点"聚合和"元素"聚合,我不能在一个事务中更新它们？
我认为AR可能更多地是关于一致性边界而不是事务边界.
交易恰好适合AR边界的事实只是巧合.
由于事务更多地是应用层关注的问题,如果您在事务中最终得到多个AR,那么它并不一定表示设计问题.
事实上,我甚至可以说,在一些100%的一致性要求场景中,您甚至可能没有选择,只能在一个事务中包含所有更改.