【发布时间】:2013-05-30 13:26:37
【问题描述】:
我们第一次尝试在我们的项目中采用领域驱动设计。我遇到的问题是实体之间的关联。你是如何做到正确的?
说,我有实体Employee 和Contract,一个简单的一对多关联。我该如何建模?
选项 1: 聚合。
问题:这里的问题是,如果我理解正确的话,在创建聚合对象时必须加载聚合中的所有实体。我不能在需要实体时延迟加载实体,因为它需要从实体引用存储库,这显然很糟糕。但是每次都从数据库中获取员工的所有合同将是一个很大的性能问题。
选项 2: 通过使用存储库(例如 ContractRepository.GetContractsForEmployee())获取员工的合同并将 EmployeeId 属性添加到 Contract 类。
问题:很难将任何业务逻辑放入实体中。我想要一个方法,比如Employee.Dismiss(),但它还需要更新员工的合同。这意味着我需要将此逻辑放入服务中。问题是,我想不出太多的逻辑只在 Employee 上运行,因此模型会变得有些贫乏,大部分逻辑都在服务内部。
您如何处理 DDD 中的这些问题?
【问题讨论】:
-
一旦您考虑“简单的一对多关联”,您就不是在做 DDD,而是在做数据库模式设计。实体之间的关联应该是行为。员工不能解雇自己,必须解雇(由有权这样做的另一个实体)。选项 2 是正确的。您不必为实体提出很多行为。如果一个领域对象在实际业务中非常简单,那么就以这种方式建模。重要的是域如何定义概念(语义),而不是对象有多少方法。
-
MikeSW 是正确的。 DDD 的一个非常重要的方面是无处不在的语言。你谈论领域的方式必须是领域专家谈论领域的方式,否则代码会变得笨拙和不直观。这听起来微不足道,但如果你做对了,那么实体就会开始建议行为。例如员工.Resign(); Contract.Terminate();
标签: oop architecture domain-driven-design