设计模式 – DDD选择聚合根

发布时间：2020-12-14 04:55:22 所属栏目：百科来源：网络整理

导读：构建时间跟踪应用程序我正在尝试确定设计聚合根的最佳方法. 基本核心实体是Client,Project,Employee,ProjectAssignment,Department,Timesheet.客户有一个或多个项目,项目有一个或多个员工(通过ProjectAssignment),一个员工属于一个部门,时间表链接项目,员工.

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

基本核心实体是Client,Project,Employee,ProjectAssignment,Department,Timesheet.客户有一个或多个项目,项目有一个或多个员工(通过ProjectAssignment),一个员工属于一个部门,时间表链接项目,员工.

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

Client -> Project -> ProjectAssignment -> Employee

关于其他总量,我有点不确定最好的方法是什么……

我刚在想…

Department -> Employee -> Person

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

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

解决方法

DDD不是关于数据结构,也不是关于这些结构之间的关系,而是关于这些数据发生的变化以及这些变化的边界. DDD在许多地方都很难解释,包括多个视觉课程或会议,人们构建一个简单的应用程序,专注于单个用户,并努力尽可能多地强加DDD原则.

领域驱动设计的核心原则是边界.当您尝试查找聚合时,首先要考虑您在应用程序中执行的进程以及您需要具备的进程,以使这些进程保持一致.比构建执行此更改的单个实体并将其与聚合中的任何其他所需实体(值对象)一起包装.然后将一个实体作为所有使用这些实体执行的进程的网守.

从数据结构开始设计是人们在DDD失败的首要原因.
从你提供给我的内容来看,你的聚合似乎是一个ProjectAssignment,也许是一个时间表,因为这里可能会有一个核心业务逻辑.所有其他的东西几乎都不是值对象(或者如果你必须使用orm的实体),可以使用简单的crud样式方法创建.关于实体和价值对象之间的差异有很多讨论和博客文章.人们倾向于给他们在域中的“对象”赋予一些意义,但对于领域专家来说,我们花费大量时间创建的那些珍贵对象只是价值,仅此而已.因此,不要将客户端或部门提升为聚合根 – 它们只是值.

不要害怕你使用crud.您在设计域时遇到的许多事情都只是域导出的价值对象.他们只是使用它们来对真实的业务实体进行操作.他们不关心如何创建客户端,如何创建部门或如何创建部门层次结构.他们只是创建它们然后编辑或删除它们.因此,用于描述客户或部门的词语将只是创建,更新或删除 – 而这些词语对于普遍存在的语言(域语言)来说是非常糟糕的候选者.无处不在的语言在DDD中是如此被低估的模式.如果你正确使用它,它将为你节省时间,你花在设计的东西,这对业务无关紧要.每次你认为你需要创造一些东西或更新一些东西 – 使用crud！不要用DDD原则打扰你自己,因为它们很简单,不适用于创建或更新等词.

请记住,只有在您可以访问域专家时,DDD才会在协作域中闪耀.同时拥有业务专家和开发人员帽子真的很难.至少将设计分组或至少成对,尝试一些事件风暴.根据我的经验,单独创建一个像样的ddd设计几乎总是会失败.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!