危险的DDD聚合根
DDD的核心是聚合。这没有问题,大家都认同。但关于DDD中的聚合方式,可能就有些问题了。下面谈一下我的观点,希望大家参与讨论。
其实当初第一次看到DDD中关于聚合根部分论述的时候,就感觉有些僵化。同时,看到jivejdon关于聚合根实现代码时,有感觉有些沉重而不自然。
DDD中的聚合根的分析设计思路大致是这样:1、业务本质逻辑分析;2、确认聚合对象间的组成关系;3、所有的读写必须沿着这些固有的路径进行。这是一种静态聚合的设计思路。理论上讲,似乎没有什么问题。但实际上,人对第一步中的业务逻辑分析就是一个渐进的过程,不是稳定不变的。不是谁都可以成为业务领域专家,就算是业务领域专家也不一定都是对的。在我看来,从时间维度和多用户场景下看,这种静态的聚合分析设计方法是根本无法保证领域模型的稳定性。
也许有人不理解,那可以打个比喻:过去几个孩子可以和爸爸妈妈高高兴兴地一家人生活在一起,但是孩子们长大后是必然要分家的。其实我只是在强调,人们对业务过程的认识是有局限性的,谁也无法避免。
DDD本来就是处理复杂业务逻辑设计问题。在论坛里经常也能看到大家用DDD去分析一些小项目的时候,大家往往为谁是聚合根而无法达成共识。这说明每个人对业务认识的角度、深度和广度都不同,自然得出的聚合根也不同。也因为这种认识的局限性,可能造成不同领域模型的聚合根是相同的(比如人)。试想,这样的情况下,领域模型怎么保持稳定。
更现实的解决方式是怎么在动态过程中尽可能地保证业务领域模型的稳定性。在我看来:对象之间是平等的,没有谁高人一等(也就是没有聚合根);场景(业务)是聚合对象行为的唯一理由;复杂的场景是由简单场景聚合而成。不管业务如何变化,总有子场景是不变的,这样就能获得最大的“维护利润”(业务不变性)。