design-patterns - DDD 选择聚合根

Question

构建时间跟踪应用程序 我试图确定设计聚合根的最佳方法。

基本的核心实体是 Client、Project、Employee、ProjectAssignment、Department、Timesheet。一个客户有一个或多个项目，一个项目有一个或多个员工分配给它(通过 ProjectAssignment)，一个员工属于一个部门，时间表将项目、员工链接在一起。

客户端似乎是一个明显的聚合根。

Client -> Project -> ProjectAssignment -> Employee

关于其他聚合，我有点不确定最好的方法是什么......

我刚在想...

Department -> Employee -> Person

或者将员工和部门完全作为单独的聚合。员工可以在一个部门，只能在一个部门。但是，部门是自引用以创建部门层次结构。

您如何处理在聚合根之间共享的实体？

Answer 1

DDD 不是关于数据结构，也不是关于这些结构之间的关系，而是关于发生在这些数据上的变化以及这些变化周围的边界。 DDD 在很多地方都没有得到很好的解释，包括 Pluralsight 类(class)或 session ，在那里人们构建一个简单的应用程序，专注于单个用户，并尽可能多地强加 DDD 原则。

领域驱动设计的核心原则是边界。当您尝试找出聚合时，首先要考虑您在应用程序中执行的流程以及您需要具备什么才能使这些流程保持一致。然后构建一个执行此更改的单个实体，并将其与任何其他需要的实体(值对象)一起包装在一个集合中。然后将一个实体提升为与这些实体一起执行的所有流程的看门人。

从数据结构开始设计是人们在 DDD 上失败的第一大原因。从你提供的信息来看，对我来说，你的聚合似乎是一个 ProjectAssignment也许还有 Timesheet ，因为这里大概会铺设一个核心的业务逻辑。所有其他的东西都只是一个值对象(或者实体，如果你必须使用 ORM)，可以用简单的 CRUD 风格的方法创建。有很多关于实体和值对象之间差异的讨论和博客文章。人们倾向于赋予他们领域中的“对象”一些意义，但对于领域专家来说，那些我们花费大量时间创造的宝贵对象只是值(value)，仅此而已。所以不要推广Client或 Department作为聚合根 - 它们只是值。

不要害怕你使用 CRUD。您在设计域时遇到的许多事情都只是域导出的值对象。他们只是使用它们对真正的业务实体执行操作。他们不在乎 Client是如何创建的，如何Department是如何创建的还是如何Department层次结构被创建。他们只是创建它们，然后编辑或删除它们。所以用词来形容Client或 Department将只是创建，更新或删除 - 这些词对于无处不在的语言(领域语言)来说是非常糟糕的候选者。无处不在的语言是 DDD 中被低估的模式。当你正确使用它时，它会为你节省大量时间，你花在设计东西上，这对业务无关紧要。每次您认为需要创建某些内容或更新某些内容时 - 使用 CRUD!不要用 DDD 原则来打扰你自己，因为当涉及到诸如创建或更新之类的词时，它们根本不适用。

请记住，DDD 仅在协作领域中大放异彩，并且仅当您可以访问领域专家时。同时拥有业务专家和开发人员的帽子真的很难。至少让设计成组或至少成对，尝试一些事件 Storm 。根据我的经验，单独创建一个体面的 DDD 设计几乎总是会失败。