domain-driven-design - 领域驱动设计——如何为公司和员工用例建模？

Question

过去几周我第一次深入研究 DDD。我正在开发一个 HR 应用程序，并且真的在与聚合根的想法作斗争。

因此当前的实体将是:

• 公司
• 员工

现在考虑到 Employee 的生命周期，首先将其作为子实体包含在 Company 中是有意义的。可以将员工添加到公司(新员工或现有员工)，然后该员工可以辞职或被解雇 - 此时员工记录可能会更新为某种状态，因此可以将其与活跃员工区分开来。

关于域逻辑，公司的每位员工都必须拥有唯一的电子邮件。因此，如果一家公司始终包含其所有员工的列表，我想可以将其建模为:

company.AddEmployee(employee) - 此方法将包含确保电子邮件唯一的逻辑。此外，它会根据他们拥有的员工数量更新公司的大小属性。 (<100 是小的，<500 是中等的，等等)

现在我看到人们讨论的最大问题是关于大型聚合。我认为这个用例会受到这种关注，因为在这个 HR 应用程序中，一家公司可能拥有 10k+ 名员工。如果我一次添加一个员工，收集所有 10k+ 似乎真的很浪费，即使只是他们的电子邮件。

将 Company 设为聚合根是否正确，还是有更好的方法？

Answer 1

建模聚合与父子层次结构无关。如前所述，它是关于事务边界的。此外，请考虑聚合提供公共(public) API 以对您的域模型执行事务。

更容易抛开父子层次结构思想，首先也是性能方面的考虑。而是思考:

Are there use cases to perform transactions (changes) on this entity without the need to apply domain rules that can only be adhered by some encapsulating root entity? That means, can this entity contain all domain logic (business rules) on its own to perform transactions on it?

在您的案例中应用这种思维方式可能有以下推理:

There are use cases where I want to modify an Employee entity where it does not make sense for the Company to check business invariants. Like, the main phone number contact information of an employee must never be empty or have invalid format.

这当然是一个人为的例子，但它表明，通过这种推理，这样的交易不需要业务不变性，而业务不变性将位于公司实体中。按照这种逻辑，让 Employee 成为一个独立的聚合是有意义的。

另外，对我来说，从战术 DDD(或者基本上也是从面向对象编程)中学习的一个关键关键是将逻辑放在数据所在的位置。如果员工拥有所有数据来执行保持事务一致性所需的逻辑，而无需询问公司，那么它本身就是一个很好的聚合候选者。

注意:当然，根据性能要求(以防子实体集合变得太大)，将属于聚合的一部分的实体单独作为聚合也是有意义的。但我不会根据性能要求开始建模聚合，而是问自己上述问题。

现在进入检查电子邮件唯一性的主题。

相关数据在哪里？您可以说，如果 Company 知道所有员工，那么它也会知道到目前为止该公司员工的所有电子邮件。但是仅仅让员工成为公司的 child 似乎并不是正确的理由。

如果您将Employee建模为自己的聚合，通常会有一个特殊的域服务维护员工聚合的集合和提供检索和修改在您的业务领域中有意义的此类聚合的访问功能 - 聚合存储库。

这也是放置问题逻辑的好地方，是否已经有员工使用该电子邮件地址？因为存储库具有提供该逻辑的数据。

剩下的问题当然是哪些代码/组件不应该在存储库上调用此逻辑？。你可以，例如有一个特殊的员工服务来协调员工的创建。但视情况而定，也可能不合适。为了帮助做出此类决定，最好了解 DDD trilemma 的含义。 .

要获得有关此类决定的更多提示，您可以查看此 Q&A在 stackoverflow 上也讨论了类似问题的领域服务。