domain-driven-design - DDD 聚合为参与者

Question

Vaughn Vernon 在此处描述了使用 Actors 作为 DDD 聚合： Vaughn Vernon on the Actor Model and Domain-Driven Design

考虑一个 Invoice 聚合：是否要使用 Azure Service Fabric Actor 的生命周期，以便 1 个 Actor 可用于保存仅 1 个 Invoice 的状态（比如标识为“ABC”），并且可靠存储表示该状态发票。或者是否需要某种 Flyweight 实现来选择可用的 Actor 实例并在调用期间加载 Invoice "ABC" 的状态？

第一个选项似乎符合 Actor 的概念，但这意味着在设计 Fabric 基础架构时需要考虑到这一点，系统中的每个 Invoice 都有一个 Actor（一个无界且无疑非常大的数字）

Answer 1

Service Fabric 绝对是为这种场景设计的。你需要巧妙地划分你的状态，以便容纳大量的参与者——你必须考虑数据的潜在大小、参与者的数量和节点的大小。

Service Fabric 不支持（还？）的是一种自动重新分区服务的方法。因此，如果您从 3 个分区开始，并且在某个时候意识到需要更多分区，则需要自己处理。您需要做一些试验来查看需要多少个分区，但一般来说，建议您从大数开始。

值得阅读此https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-concepts-partitioning/并查看评论。