在领域驱动设计中对聚合进行设计与存储

阅读数:1851 2014 年 12 月 18 日

话题:语言 & 开发架构

在使用领域驱动设计的过程中,使用者们对于如何创建设计良好的聚合(aggregate)这一模式始终知之甚少。在Vaughn Vernon近期发布的两篇文章中,他为读者介绍了组合聚合边界的相关指南,并且介绍了在对聚合进行存储的时候如何使用ORM 的替代技术

《实现领域驱动设计》(Implementing Domain-Driven Design)一书的作者 Vaughn 为了简化聚合的组合,定义了四条他认为很有帮助的规则:

  • 在一致性边界之内确保不变性,这也暗示着在一个事务中应该只对一个聚合进行变更。
  • 设计尽量小的聚合,尽可能实现一个实体这样的最小聚合。
  • 只通过唯一标识的方式对其它聚合进行引用,意味着不应当存在在某个聚合中直接访问另一个聚合的情况出现。
  • 在一致性边界之外使用最终一致性方式。实现这一点可以使用领域事件进行通知,领域中的其它部分可以在一个新的事务之中对其它聚合进行变更。

Vaughn 强烈建议首先从第二条规则开始实施,让每个实体成为一个聚合根,不存在任何例外的情况。接下来再为该聚合添加所有字段与属性,以使该聚合在创建时保证处于某个有效的状态下。

Vaughn 所建议的下一步骤,是与领域专家进行协同工作,以找中哪些聚合是必须在同一个事务中进行变更的,以及哪些聚合是可以由某些变更进行触发的。Vaughn 在这里提出了一点警告,领域专家都倾向于声明所有实体都是必须在同一个事务中进行变更的,而这种情况其实并不多见,很有可能是由于这些专家之前的工作经验都是与数据库密集型系统打交道所导致的。

Vaughn 一直在寻找某种比对象 - 关系 / 映射(ORM)框架更好的方法对聚合进行保存,他曾考虑以JSON格式对聚合进行序列化,并将结果保存在某个文档数据库中。在对领域事件进行操作时,这些事件必须在聚合进行变更时保存在同一个事务中,否则一旦存储机制出错,整个系统的数据就有可能产生不不一致。但使用文档数据库的一个问题在于,多数文档数据库都不支持ACID 的事务功能,对于那些无法接受不一致的系统来说,这实际上就断绝了使用文档数据库的可能性。因此 Vaughn 转而寻找某种支持事务与 JSON 的数据存储系统,目前他所找到的一个产品是PostgreSQL 9.4的 beta 版本,他已在一些小型示例中成功地应用它作为聚合的存储机制了。

Vaughn 还撰写了关于《高效聚合设计》的一系列共三篇文章。

在早些时候,Julie Lerman也在文章中介绍了如何在边界上下文之间共享数据的话题。

查看英文原文:Designing and Storing Aggregates in Domain-Driven Design