数据库选型对领域建模的影响

如果单独从领域建模的角度看，当然应该只从业务角度分析系统的领域模型，并通过分析各个领域对象之间的关系（如合成、聚合、关联以及依赖关系）来设计聚合，考虑聚合的概念边界，并将各个实体和值对象分配到聚合之中。然而，从技术实现的角度，基于质量属性做出的数据库选型，可能会反过来影响领域建模的设计。

例如，在对文档服务平台进行领域建模时，一个Document（不包含文档的内容，而是文档的元数据信息）会有多个修订版本Revision。毫无疑问，Document需要定义为一个单独的聚合。从业务相关性看，Document与Revision之间的关系，应该是OO聚合的关系，即构成相对松散的整体-部分关系。这会得出两种设计方案：

• 倘若修订版本需要做单独的生命周期管理，可考虑将其设计为一个单独的聚合，并在Revision的聚合根实体中，将Document的id作为它的外键
• 倘若不考虑单独管理文档的修订版本，也可将其作为非根实体，放到Document聚合内部

然而，在进行架构决策时，考虑到数据的强一致性，可能会选择类似PostgreSQL之类的关系型数据库来存储文档元数据；而从可扩展性与高效检索的角度考虑，则文档内容以及文档的修订版本，又需要存放在文档型的NoSQL数据库中。

换言之，领域模型中的Document类与Revision类对应的持久化模型分属两个不同的数据库，从技术选型与资源独占性的角度考虑，它们甚至属于不同限界上下文对应的微服务。

这就意味着Document类与Revision类应该被设计为分属两个不同限界上下文边界的领域模型。既然分属不同架构边界，二者就不可能放到同一聚合中，即便分属不同的聚合，也需要警惕，不能让二者出现任何类引用的依赖关系。

当然，从这个角度来看，也充分证明了以下两个设计原则的必要性：

• 在限界上下文内部开展领域建模：尝试先确定限界上下文，再在限界上下文边界内各自进行领域建模
• 聚合之间应通过ID建立关联关系：一个聚合与另一个聚合各自演化，它们的生命周期是独立的，即便二者在同一个限界上下文

遵循领域驱动设计方法的领域建模，需要考虑限界上下文和聚合的双重边界，这一约束使得建模人员的工作变得更困难，但它带给设计的价值却是显而易见的。