建立时间跟踪应用程序我试图确定设计聚合根的最佳方式。DDD选择聚合根
基本核心实体是客户端，项目，员工，项目分配，部门，时间表。客户有一个或多个项目，一个项目有一个或多个员工分配给它（通过ProjectAssignment），一个员工属于一个部门，时间表将项目，员工链接在一起。
客户端看起来像一个明显的聚合根。
Client -> Project -> ProjectAssignment -> Employee
至于其他集合体我有点不知道什么是最好的方式去将...
我在想......
Department -> Employee -> Person
还是有员工和部门完全分开汇总。员工只能在一个部门和一个部门。然而，部门是自我参考来创建部门层次结构。
你如何处理在聚合根之间共享的实体？
在设计聚合时，应该考虑有界上下文和不变量。 根据我的理解，您只能讨论一个有界的上下文。 关于不变量，您指定一个员工只能在一个离职中。 从我可以告诉聚合根（AR）是：Client，Project，Employee和Department。
ProjectAssignment应该是Project AR中的一个值对象，它包含雇佣ID和其他数据（如分配日期）的列表。
Timesheet可能是Employee中的一个值对象，其中包含Projects IDs和其他数据（如开始日期和结束日期）的列表。
Employee AR可以持有对其Department ID的参考，强制您的雇员只属于一个部门。
DDD不是关于数据结构，也不是关于这些结构之间的关系，而是关于这些数据上发生的变化以及这些变化的边界。 DDD在很多地方很少被解释，包括多元视觉课程或会议，人们在这里建立一个简单的应用程序，关注于单个用户，并尽力将尽可能多的DDD原则强加给他们。
领域驱动设计的核心原则是边界。当您尝试查找聚集时，首先考虑您在应用程序中执行的流程以及您需要具备哪些流程，以便使这些流程保持一致。比构建一个执行此更改的单个实体并将其与任何其他所需实体（值对象）合并在一起。然后提升一个实体作为所有使用这些实体执行的进程的守门人。
从数据结构开始设计是人们在DDD失败的第一个原因。 从你提供给我的看来，你的总计似乎是ProjectAssignment，也许是Timesheet，因为这里可能会奠定核心业务逻辑。所有其他的东西几乎都不是一个价值对象（或实体，如果你必须使用orm），可以用简单的crud风格的方法创建。关于实体和价值对象之间的差异有许多讨论和博客文章。人们倾向于给他们在他们领域中的“对象”赋予一些含义，但对于领域专家而言，我们花费这么多时间来创建的那些宝贵对象只是价值观，而已。所以不要将Client或Department作为一个聚合根来推广 - 它们只是价值观。
不要害怕你使用crud。您在设计域时遇到的许多事情将只是域导出的价值对象。他们只是用它们来对真正的商业实体进行操作。他们不在乎如何创建Client，如何创建Department或如何创建Department层次结构。他们只是创建它们，然后编辑或删除它们。所以用于描述Client或Department的词将只是创建，更新或删除 - 而这些词对于无处不在的语言（域语言）来说是非常差的候选者。无处不在的语言在DDD中被低估了很多。当你正确使用它时，它会为你节省时间，你花费在设计上的东西，这对业务无关紧要。每当你认为你需要创造一些东西或更新某些东西时，请使用crud！不要用DDD原则来打扰你的自我，因为当涉及到创建或更新等单词时，它们并不适用。
请记住，DDD只能在协作域中发光，并且只有在您有权访问域专家时才会发光。很难同时拥有业务专家和开发人员的帽子。至少在团队中或者至少成对地进行设计，尝试一些事件风暴。根据我的经验，单独创建一个体面的ddd设计几乎总是会失败。
选择一个聚合根时，您可以选择“事务一致性”和“最终一致性”。当你的业务规则允许你更喜欢最终一致性。
让我们来看看员工和部门。检查您的使用案例：部门/员工变更是否可以使用最终一致性（用户是否同意有时会看到过时的orhanizational结构？）
如果是将部门和员工视为单独聚合。通过其编号创建员工参考部门。
如果不合适（例如，用户不会在时间表报告中容忍员工的错误部署），那么使部门拥有一个持有员工实体集合的集合。
更多关于这个话题，你可以在IDDD书沃恩弗农发现： https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
很好的答案！ DDD是否适用于长时间的业务处理引擎（一些运行几分钟/小时的复杂算法），用户交互只是少数输入？这是一个非“协作域”问题的例子吗？ – Narayana