Question

在DDD中，Aggregate应代表事务边界。需要涉及多个聚合的交易通常表明应该改进模型，或者应该审查交易要求，或者两者兼而有之。

这是指每个聚合根INSTANCE还是每个聚合的事务边界？

假设我在每个＆＃34; Node＆＃34;中有一个名为＆＃34; Node＆＃34;的聚合根。我有一个＆＃34; Fields（Value objects）＆＃34;的集合。每个＆＃34; Field＆＃34;属于Type，可以是Type＆＃34; Node＆＃34;。在我的情况下，如果它是Type＆＃34; Node＆＃34;，我会将Id存储到＆＃34; Node＆＃34;聚合根。

Node (AggregateRootID 1)
---> Field1 : String (John)
---> Field2 : String (Doe)
---> Field3 : Node (AggregateRootID 2)

Node (AggregateRootID 2)
--> Field1 : String (Jane)
--> Field2 : String (Doe)

如果我有一个更新两个AggregateRoots实例的事务，那有效吗？

或者这是否意味着我有＆＃34; Node＆＃34;聚合和＆＃34;元素＆＃34;聚合我不能在一次交易中更新它们两个？

Answer 1

我认为AR可能更多地是关于一致性边界而不是事务边界。

交易碰巧很好地适应AR边界这一事实只是巧合。

由于交易更多地是应用程序层关注的问题，如果您在事务中最终得到多个AR，那么它并不一定表明存在设计问题。

事实上，我甚至会说在一些100％一致性要求的情况下，您甚至可能没有选择，只能在一次交易中包含所有更改。

Answer 2

假设您正好在Async模型中使用CQRS，那么很可能您的聚合边界将成为该事务中唯一更改的聚合。现在，如果您在同步模型中使用CQRS，或者即使您正在进行RPC N-Tier开发风格，那么完全相反，在客户端调用中，对您的数据模型执行了很多更改。在最后一种情况下，您在同一事务中肯定会有多个聚合实例（即：具有事务范围的工作单元）。

如果不了解有关系统架构的更多信息，我认为您的问题没有正确或错误的答案。 DDD本身无法为您的系统范围的事务设置规则。我可以肯定的是，如果你碰巧使用带有cqrs的异步，基于事件的系统并且碰巧每个事务更改了多个聚合，那么，这只是我的看法，似乎没有右。

多个聚合每个事务的根INSTANCES

2 个答案: