危险的DDD聚合根
原文:危险的DDD聚合根
DDD的核心是聚合。这没有问题，大家都认同。但关于DDD中的聚合方式，其实我还是有些担心，下面说说我的想法，希望大家参与讨论。
其实当初第一次看到DDD中关于聚合根部分论述的时候，就感觉有些僵化。DDD中的聚合根的分析设计思路大致是这样：1、业务本质逻辑分析；2、确认聚合对象间的组成关系；3、所有的读写必须沿着这些固有的路径进行。
这是一种静态聚合的设计思路。理论上讲，似乎没有什么问题。但实际上，人对第一步中的业务逻辑分析就是一个渐进的过程，不是稳定不变的。不是谁都可以成为业务领域专家，就算是业务领域专家也不一定都是对的。在我看来，从时间维度和多用户场景下看，这种静态的聚合分析设计方法是根本无法保证领域模型的稳定性。
也许有人不理解，那可以打个比喻：过去几个孩子可以和爸爸妈妈高高兴兴地一家人生活在一起，但是孩子们长大后是必然要分家的。其实我只是在强调，人们对业务过程的认识是有局限性的，谁也无法避免。
DDD本来就是处理复杂业务逻辑设计问题。我看到大家用DDD去分析一些小项目的时候，往往为谁是聚合根而无法达成共识。这说明每个人对业务认识的角度、深度和广度都不同，自然得出的聚合根也不同。试想，这样的情况下，领域模型怎么保持稳定。
更现实的解决方式是怎么在动态过程中尽可能地保证业务领域模型的稳定性。在我看来：对象之间是平等的，没有谁高人一等（也就是没有聚合根）；场景（业务）是聚合对象行为的唯一理由；复杂的场景是由简单场景聚合而成。不管业务如何变化，总有子场景是不变的，这样就能获得最大的“维护利润”（业务不变性）。
作为企业软件开发而言，最大的挑战就是业务变化。这一方面来源于业务本身的变化（应用系统应用不断深入和推广），另一方面是我们对业务认识不断深入的过程。不能适应变化的系统只有死路一条。复杂的业务要求软件架构必须具备很强的适应能力。如前面所说，这是一个渐进的过程。DDD本身就是为了解决复杂业务的软件开发问题的。“如何避免颠覆式修改”是最大的挑战。如果发现找的聚合根是错误的，那领域模型还可重用的价值还有多大，这种代价和成本是否能够承受？
核心观点：
- 每个人对业务认识的角度、深度和广度都不同，得出的聚合根也就会不同；这才有了很多时候我们无法对谁是聚合根以及聚合根的边界大小达成共识；
- 我们对业务的认识是一个不断深入的过程，在这个过程中我们的模型也会相应调整；
- 从DDD的最后落地实现角度来看，最终出来的是一个个聚合。但是因为聚合不仅仅只是一个根实体，而是还内聚了一堆子实体和值对象。那它的这种内聚结构对于后期因各种原因而发现原来的聚合是错误的时候，此时模型重构的成本和代价会相对于“一个所有Entity对象都地位平等的模型”的重构成本会更大，特别是在引入了Event Sourcing时问题更加凸显，这点也可见我上篇发表的帖子；
最新文章
- canvas流星月亮星星银河
- Android 使用js调用Java
- 什么是multipart/form-data请求
- outlook 用宏发邮件
- 写入数据到Plist文件中时,第一次要创建一个空的数组,否则写入文件失败
- [Redux] Passing the Store Down with <Provider> from React Redux
- 一步一步学数据结构之n--n（Prim算法）
- python自学笔记（十）语句与数据结构应用
- 如何让Spring MVC接收的参数可以转换为java对象
- 下载Ext JS 5.1 gpl版本的方法
- js中json的添加和指定位置的删除
- SqlServer_存储过程
- SSM知识点与整合之Spring知识点（pom.xml需要依赖的jar或者plugin）
- 『TensorFlow』函数查询列表_张量属性调整
- nginx日志分割配置实例
- Lintcode: Minimum Subarray 解题报告
- Zabbix应用一:Zabbix安装
- csharp:Conversion Between DataTable and List
- 不用split调转字符串
- shiro 拦截器