细心的人可能会发现,之前我这个图中的领域实体对象圆其实有两种画法,一种是底部有一条线,另一个是左侧有一条线。这样画的目的是为了进一步区分实体中那些是聚合根,那些是普通实体。
那么什么是聚合根,按照我的理解,就是当这个实体被创建时,他可以代表这个创建的最关键的线索,就是聚合根。可能这么解释还是感觉不明白,那么我就用一个项目的案例来说明,在金融系统中,我们经常有一个设计是“交易流水”,比如一笔支付单据,就有一笔支付交易流水,那么这个流水就代表了这个订单一次支付处理过程,通过这个流水以及相关联的日志,我们可以事后得出,这笔订单如何从一个初始状态,变为了已经支付状态,所以往往我们为了回溯,我们会将这个流水以及产生的信息,都会持久化到数据库中,以方便后面业务的核查。 在这里:这个支付过程和这个交易流水就是密切关联的,可以这么说,交易流水就是为了这次支付过程而诞生的,而且我们通过这个交易流水,我们也能够反应当初那个过程。在这个交易过程中,我们可以认为这个交易流水就是聚合根,一切的开始都是从他诞生开始,事后他也代表了一次过程,那么这就是我理解的聚合根。
再回到我们实体划分里面,你会发现,众多的实体的诞生,都是因为一个动作,那么如果这个实体动作也反过来反应一次业务动作,那么我们就可以这个动作为一次聚合,同时认为这个实体是这个聚合的聚合根。
那我们为什么要区分聚合根了?有两方面的原因:在微服务中,为了系统的健壮性,我们可以要求所有的微服务都应该满足幂等性要求,如果所有的微服务都满足这个特性,那么对于整体系统的高可用以及稳定性都会带来大幅度的提高,那么当一次调用,都会产生一条数据以及对象代表这次调用,通过对象的去重,我们就得到了相应服务的幂等性;第二个原因,就是通过聚合根,我们可以从数据层面就能够反应整个系统的调用过程,而且在一些特定的场景,我们完全可以有条件针对聚合根的数据,来回溯系统的演进过程。
那么针对聚合根还有几个特性,我们需要了解一下:一次聚合的过程仅产生一个聚合根;聚合根也是在微服务体系内的,不要设计跨服务的聚合根,特别不要设计长事务的聚合根。
在例举的案例里面,底部有一条线圈就是一个聚合根。
可以看到我们认为一次Command调用就是一个聚合,Command对象就是相应的聚合根,那么我们就可以将所有的Command对象持久化到数据库中,这样可以代表了整个系统在Command侧的演进历史。这样对后续业务和技术的支撑都是非常的有利。