Domain driven design 这样做有意义吗？

让我们假设一个呈现这些规范的项目：

• 每个

  员工

  都可以组织一次

  会议

  邀请其他

  员工

• 每个

  员工

  都可以接受参加

  会议的邀请

  ，但不会超过最大

  参与人数

  s

• 员工

  创建者的任何

  经理

  都可以随时取消

  会议

在国际海事组织中，不变量是：

• 只要创建者（

  员工

  ）存在（未删除或标记为已删除），会议就存在
• 任何时候都不应召开

  会议

  ，会议的参与者人数不得超过预期限制
• 任何取消其创建的

  会议的
  员工
  也应取消/删除该
  参与

• 当

  经理

  取消

  员工的
  会议
  时，应同时删除
  会议
  和
  参与

我是否应该：

• Employee

  是一个聚合根目录，包含其创建的

  会议的集合
  会议
  因此是
  员工的内部实体
  并包含
  参与的集合
  Manager作为另一个聚合根目录，包含其
  Employee
  s的集合
  

因此，只有将根集合起来：

员工

和

经理

事实上，经理可能会被解雇，然后就不再是员工不变量的一部分，反之亦然

详细信息：
_

Employee

将提供一种方法

createParticipation

，封装对重要规则的检查，如是否超过了参与者的最大数量。
_

员工

还将提供一个工厂来创建

会议

，允许始终将正确的

员工ID

分配给

会议

_只创建两个存储库：

EmployeeRepository

和

ManagerRepository

，避免直接访问各自的内部部件。
（这只涉及创作，删除也类似）

因此，为了创建一个

会议

的

参与

，我的切入点将是我通过

员工档案

检索的创建者（

员工

）

---

遵循严格的DDD实践有意义吗

你的员工总数太大了。这会产生并发问题。如果两名员工同时接受邀请，会发生什么？一个事务将回滚，因为它们试图修改相同的聚合。除非你设计了一些奇特的冲突解决逻辑

---

P>而是把参与和会议看作是单独的集合。 事实上，我同意。目前，这就是我所拥有的：参与和会议是聚合的根，正如你们所提倡的。但是，不变量是什么：“如果一名员工被删除，那么其所有创建的会议+与其相关的参与也应该被销毁”。如何原子化处理？在这种情况下，我应该使用最终一致性吗？我看不到事务一致性的好处。会议计划在几小时、几天甚至几周之前举行。没有人会注意到任何差异。好的，但是，如果

会议

和

参与

都是聚合根，那么如何处理规范：“不超过最大参与者数量”？我正在阅读Evan的蓝皮书，在他的“采购订单”（处理意外数量的OrderLineItems）示例中，他通过将

order

和

OrderLineItems

收集到一个聚合根中来解决问题，其入口点是

order

。我的用例是类似的，不是吗？会议应该有一个引用参与（ParticipationId）的值对象列表。这篇文章可能会有帮助：非常感谢您的建议：）我将参与作为一个简单的值对象，引用用户实体的UserId（这样我就可以链接整个图形数据库）。有许多参与者参加的会议