oop - 在 DDD 中实现关联的正确方法是什么？

Question

我们第一次尝试在我们的项目中采用领域驱动设计。我的问题是实体之间的关联。你如何做对？

说，我有实体 Employee和 Contract ，一个简单的一对多关联。我该如何建模？

选项 1:总计的。

问题:这里的问题是，如果我理解正确的话，在创建聚合对象时必须加载聚合中的所有实体。我不能在需要时延迟加载实体，因为它需要从实体中引用存储库，这显然很糟糕。但是每次从数据库中获取所有员工的契约(Contract)将是一个很大的性能问题。

选项 2:通过使用存储库(例如 ContractRepository.GetContractsForEmployee() )并添加 EmployeeId 来获取员工的契约(Contract)属性(property)到Contract类(class)。

问题:很难将任何业务逻辑放入实体中。我想要一个方法，比如说，Employee.Dismiss() ，但它还需要更新员工的契约(Contract)。这意味着我需要将此逻辑放在服务中。问题是，我想不出很多仅在 Employee 上运行的逻辑。因此该模型会变得有些乏力，大部分逻辑都在服务内部。

在 DDD 中你是如何处理这些问题的？

Answer 1

这只是我的看法......不知道你的域。

一、here是一个很好的阅读资源(关于聚合和根的部分)。

在 DDD 术语中，Employee和 Contract都是 实体 (因为他们都有一个身份)。

“聚合在一个或多个实体周围划出一个边界。而且:每个聚合都有一个根实体，它是聚合的唯一成员，聚合之外的任何对象都被允许持有对其的引用。”

问题是:做Employee和 Contract与 Employee 形成聚合是根实体？显然不是，因为其他域实体也可以引用 contract ，并且合约 ID 是全局唯一的，不仅在 Customer 内.

因此，考虑到这些规则，Employee和 Contract都是 聚合根 .

然后:“只能通过查询直接获得聚合根；所以这意味着我们应该为每个聚合根拥有一个存储库。”

所以在这种情况下，我们有一个 EmployeeRepository和一个 ContractRepository .

考虑到所有这些，我不会在域模型中添加员工和契约(Contract)之间的关系；但要分开对待。毕竟，如果您需要Employee ，你不一定需要他的contracts同样，它们都是不同的方面。

选项 2 是我会选择的:使用 ContractRepository以获得您感兴趣的契约(Contract)。如果需要，您可以添加一个域服务，负责在需要时聚合员工和契约(Contract)。

如果您还定义了 Company实体，然后解雇员工可能是该实体的工作。