一次关于聚合根的激烈讨论

背景

以前有同事在分享DDD在闲鱼商品详情页的实践时，你们对闲鱼团队领域建模关于商品详情页的聚合根建模表示不认同。 由于这是面向页面建模，不是面向领域建模，将微服务拆分和领域建模混为一谈了 因而我以聚合根定义做为引子，结合组内在实践DDD过程当中，聚合根随着业务查询复杂而致使聚合根不断膨胀的问题，提出借鉴CQRS读写分离的理念，来解这个问题。 详见DDD-CQRS能解聚合根的问题吗 引起了你们对领域模型的从新思考和激励讨论。历经3小时得出了一些结论，达成了共识。

讨论过程

一般咱们说领域建模不该该去考虑微服务架构，工程结构，应该专一于业务。 但在实践过程当中发现这并非一个好的方式，或者说是可落地的。由于业务领域建模完成后，仍是要反映到系统架构中， 最终是要落地到代码实现，经过代码来表达出领域模型。因此说咱们的讨论不该该是脱离 系统架构的。可是当咱们发现业务领域建模完，经过代码实践一段时间后，发现代码模型腐化了，这时候 咱们首先思考的方向不该该是经过代码来纠正，而是应该回归到业务建模。

结论

聚合根

• 聚合根表明的是一个领域边界
• 聚合根的内容要保证数据一致性（这里的一致性指的不是数据持久化的事务一致性，而是业务数据的一致性，包含业务上的业务校验） 好比订单和订单详情，一个没有订单详情的订单是不完整的
• 聚合根里面有多少个实体，由领域建模决定
• 永远不要删除聚合根 聚合根之间有引用，若是删除了聚合根，会致使关联聚合的数据不一致 这边很容易和实体的生命周期从属于聚合根搞混了。这边的依赖是关联依赖，实体依赖聚合根是has a
• 聚合根引用聚合根值id/或者id值对象

实体

• 实体通常从属于某个聚合根，要否则就能够定义成聚合根了
• 实体有本身的生命周期，他的生命周期从属于聚合根。也就是聚合根没有，实体也就没了 好比我能够对订单详情的数据进行编辑，删除。
• 聚合根与实体的关系一般是1:N 由于若是是1:1,一般不须要定义实体了。直接放在聚合根里面，不须要惟一id了。

注意，聚合根里面没有实体，并不意味着数据库就只有一张表，能够设计成多张表。DB设计和领域建模没有关系

• 能够单独更新聚合根中实体数据 不是说只能有一个方法saveAggr(),能够有saveEntity()方法

案例

case 1:

品牌信息和店铺 店铺依赖品牌，可是店铺有本身独立的生命周期。他们的数据没有一致性要求。因此店铺是一个聚合根

case 2: 门店与门店商品

门店商品有本身的价格，返佣。须要单独编辑，是一个实体。脱离了门店后没有生命终结。 下期问题 目前咱们只讨论了实体类型的聚合根，没有讨论业务过程的聚合根，好比转帐

关注公众号【方丈的寺院】，第一时间收到文章的更新，与方丈一块儿开始技术修行之路

引用

www.jianshu.com/p/e6c2fdef8…