Domain driven design 聚合根、聚合、实体、值对象

在查看上述标题中提到的术语时，我正在努力解决一些实现细节问题

有人能告诉我我的解释是否正确吗

作为参考，我看一个CRM域

作为一个聚合者，我可以看到一个客户

它可能有实体，如地址，其中包含街道、邮政编码等

现在有了类似于联系和活动的东西，这至少应该是聚合。对吗？现在，如果联系人和活动具有复杂的业务逻辑。例如，“每次创建订单类型的联系人时，应启动订单工作流”

那么联系人是否需要是聚合根？这可能会对实施产生什么影响

此外，在查找和事件源时，每个聚合是否都有自己的流？在这种情况下，客户可能有数千项活动

---

如果有人能指导他们我对哪一部分的理解是正确的，我对哪一部分的理解与一般解释不同，那就太好了。

你所说的“至少”是什么意思

聚合是一个或多个连接实体的集合。只能从其根实体（也称为聚合根）访问聚合。聚合定义了必须始终保留的实体的事务边界。Jimmy Bogard对聚合有很好的解释

使用事件源时，每个聚合都应该有自己的流。流用于构造聚合，没有理由让多个聚合使用同一个流

---

你应该尽量保持你的体重。如果您希望您的客户对象具有数千个活动，那么您应该考虑是否可以将这些活动设计为单独的聚合，只要其边界确保您不会使系统处于无效状态。

对于如何建模一种类型的域，没有通用的解释，因为每个域都是唯一的。CRM域可以按照您所描述的或其他方式建模。我建议您根据自己的理解定义聚合/实体/VO，并询问具体问题，而不仅仅是一个模糊的示例。只有一件事：

地址通常是值对象的经典示例。你确定你需要它作为实体吗？你的权利，地址应该更像是一个值对象。因为它不需要被识别，并且总是只存在于给定的aggregate中