聚合的存储库和根源

时间:2015-06-06 23:25:31

标签: domain-driven-design ddd-repositories

我正在阅读Eric Evans DDD的一本书。 我发现了一个矛盾。

关于聚合的章节:

  

选择一个ENTITY作为每个AGGREGATE的根,并控制所有   通过根访问边界内的对象。

有关存储库的章节:

  

必须通过a全局访问持久对象的子集   基于对象属性进行搜索。根本需要这种访问   通过遍历不方便到达的聚集。他们是   通常是ENTITIES,有时是内部复杂的VALUE OBJECTS   结构,有时枚举VALUES。提供对其他人的访问   对象混淆了重要的区别。

     

仅为实际需要的AGGREGATE根提供REPOSITORIES   直接访问。

可以得出结论,聚合的根可以是:

  • 实体
  • value object
  • 枚举值

我正确理解了一切吗?

或者可能是对的:

仅为

提供存储
  • 聚合根
  • 值对象
  • 枚举值 ?

什么是枚举值(需要自己的存储库!)?

1 个答案:

答案 0 :(得分:0)

Per @Marco's comment above, the root of an aggregate can only be an entity (i.e. something with an ID property). An example of this would be an Order object. No matter how many attributes you change on an Order its quality is determined by its Id property and nothing else. A value object (often implemented as a struct in many languages) does not have an ID. A common example of this would be a Money value object with a Dollars property and Cents property. Because it has no ID, the concept of querying it by ID does not apply, and thus the concept of a repository does not apply. An aggregate could have a value object as a property, though (e.g. the Total property on an Order aggregate). An enumerated type is just a list of name/value pairs. It uses the enum keyword in several languages. Again, there's no ID for the enum nor any of its members, so the concept of a repository does not apply. The concept of an enum is useful in DDD because it helps express the domain model better than, say, magic numbers e.g. order.Status = OrderStatus.Submitted vs order.Status = 1.