作为我的域模型的一部分，假设我有一个WorkItem对象。该WorkItem对象与查找值有多种关系，例如：
WorkItemType：
Priority：
可能还有更多，例如Status,Severity等...
DDD 指出，如果聚合根中存在某些内容，则不应尝试在聚合根之外访问它。因此，如果我希望能够添加新的 WorkItemType（如 Task）或新的 Priorities（如 Critical），这些查找值是否需要与它们自己的存储库聚合根？这似乎有点矫枉过正，特别是如果它们只是一个键值对。我应该如何允许用户修改这些值并仍然遵守聚合根封装规则？
While the repository pattern as described in the blue book does emphasize its use being exclusive to aggregates, it does leave room open for exceptions. To quote the book:
Although most queries return an object or a collection of objects, it also fits within the concept to return some types of summary calculations, such as an object count, or a sum of a numerical attribute that was intended by the model to be tallied. (pg. 152)
This states that a repository can be used to return summary information, which is not an aggregate. This idea extends to using a repository to look up value objects, just as your use case requires.
Another thing to consider is the read-model pattern which essentially allows for a query-only type of repository which effectively decouples the behavior-rich domain model from query concerns.
Landon，我认为唯一的方法是让这些值对聚合根。我知道这可能看起来有点矫枉过正，但这是 DDD 将事物分解为小组件。
我认为使用存储库是正确方法的原因是：
请记住，DDD 只是一套指导方针，而不是硬道理。如果您认为这太过分了，您可能想要创建一个查找，将这些对作为值对象返回。如果您没有在应用程序中添加值对而是通过数据库添加值对的功能，这可能会特别有效。
作为旁注，好问题！有很多关于这种情况的博客文章......但并不是所有人都同意最好的方法来做到这一点。
Not everything should be modeled using DDD. The complexity of managing the reference data most likely wouldn't justify creating aggregate roots. A common solution would be to use CRUD to manage reference data, and have a Domain Service to interface with that data from the domain.
Do these lookups have ID's ? If not, you could consider making them Value Objects...