cqrs - 事件溯源 - 流设计

Question

我坐在这里研究 CQRS 和事件溯源，非常有趣的话题。当谈到流设计和聚合根时，我觉得有点不知所措。你怎么做呢？
假设我有一个 UI，我可以在其中向篮子中添加东西，在篮子中生成一条线。
我会不会:

流公关篮(附有基本信息，如运输细节、姓名、电子邮件等)

一条溪流公关网

所以我会有很多流

流/篮-[basketid]

流/篮-[basketid]

基本上我只通过网络发送最少的数据。
或者我只是有一个流

流/篮-[basketid]

每次我在我的篮子里加一条线时，我都会把整个篮子放在电线上。
据我了解，最好有一对多的流，而不是一个大的流/篮流。还是我在这里也弄错了？
我在这里的重点是流。这种设计的任何“最佳实践”:链接、书籍等都将被应用。

Answer 1

How do you do it?

从观看开始 All Our Aggregates are Wrong (Mauro Servienti，2019 年)，它考虑了代表数字购物车可能需要多少不同的聚合体的问题。

我倾向于将聚合视为信息图 - 如果两条信息必须一起更改(A 更改，因此 B 也必须立即更改；或者 A 不能更改，因为其允许值的范围受 B 约束) ，那么它们属于同一个聚合。聚合的边界将紧密耦合在一起的信息与其他所有信息分开。
因为分布式事务很难，所以我们希望我们的聚合以这样一种方式存储，即更改聚合只需要持有一个锁。例如，我们通常不会将聚合的单个实例分布在多个数据库中，因为确保所有数据库在“同一”时间以完全正确的方式进行更改真的很难。
我们通常将所有紧密耦合在一起的信息存储在一个事件流中，原因完全相同:只需要管理一个锁。