查找值应该建模为聚合根吗？

Question

作为我的域模型的一部分，假设我有一个WorkItem对象。 WorkItem对象具有多个查找值的关系，例如：

WorkItemType：

• 用户故事
• 错误
• 增强

Priority：

• 高
• 中
• 低

可能会有更多内容，例如Status，Severity等......

DDD声明如果聚合根目录中存在某些内容，则不应尝试在聚合根目录之外访问它。因此，如果我希望能够添加像Task这样的新WorkItemTypes，或者像Critical这样的新优先级，那么这些查找值是否需要与自己的存储库聚合根？这似乎有点矫枉过正，特别是如果它们只是一个关键的价值对。我应该如何允许用户修改这些值并仍然符合聚合根封装规则？

Answer 1

虽然blue book中描述的存储库模式确实强调其对聚合的独占使用，但确实为异常留出了空间。引用这本书：

  

虽然大多数查询都会返回一个对象或一组对象   也符合概念，以返回某些类型的摘要   计算，例如对象计数或数字的总和   要计算的模型所要求的属性。   （第152页）

这表明存储库可用于返回摘要信息，而不是聚合。这个想法扩展到使用存储库来查找值对象，就像您的用例所需。

要考虑的另一件事是read-model pattern，它实质上允许仅查询类型的存储库，它有效地将行为丰富的域模型与查询问题分离。

Answer 2

兰登，我认为唯一的办法就是让这些价值对聚合起来。我知道这可能看起来有点过头了，但那是DDD把东西制成小部件。

我认为使用存储库的正确方法是：

• 用户需要能够独立于工作项添加这些值对。
• 值对没有本地唯一标识

请记住，DDD只是一套指导方针，而不是硬道理。如果您认为这有点过分，则可能需要创建一个将对返回为值对象的查找。如果您没有在应用程序中添加值对的功能，而是通过数据库，这可能会特别有效。

作为旁注，好问题！有很多关于这种情况的博客文章......但并非所有人都同意最好的方法。

Answer 3

并非所有内容都应使用DDD建模。管理参考数据的复杂性很可能不足以证明创建聚合根。一个常见的解决方案是使用CRUD来管理参考数据，并使用域服务与域中的数据进行交互。

Answer 4

这些查找是否有ID？如果没有，你可以考虑制作它们Value Objects ......