Domain driven design 作为行动者的DDD聚合

Vaughn Vernon在这里描述了使用参与者作为DDD聚合：

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

---

第一个选项似乎符合参与者的概念，但这意味着结构基础结构的设计需要考虑到这一点，系统中的每个发票都有一个参与者（一个无界且无疑非常大的数字）

服务结构绝对是为这种场景而设计的。您需要聪明地划分您的状态，以便能够容纳大量参与者——您必须考虑数据的潜在大小、参与者的数量和节点的大小

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

值得一读，看看评论