浅谈DDD中的聚合

在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。

为什么要使用DDD？

DDD分为战略部分跟战术部分，相信大家都认同DDD的核心在战略而非战术。而战略方面的核心我认为在业务建模，领域划分、统一语言等都在为业务建模服务。

为什么业务建模重要?

以前的开发流程有什么问题？

先说结论，开发人员交付的程序对业务方，产品人员，测试人员来说就是一个黑盒子。除了开发人员自己，没人知道盒子里有什么。当新的需求加入来，需求方，产品人员，甚至测试人员都认为可行，开发人员却给出相反结论。

回顾一下以前的开发流程 大致可以归结为以下步骤：(开发跟测试人员最好能参与需求分析)

1. 业务方描述抽象需求
2. 产品将需求转化为可落地的产品(需求具像化,PRD)
3. 开发人员根据产品的PRD开发
4. 测试人员根据产品的PRD测试
5. 产品人员验收
6. 业务方验收

依照经验来说,在整个流程中开发人员是耗时最长的。与此同时测试人员可能在编写测试用例，而业务方跟产品人员在这段时间内是阻塞的。最终的程序质量靠测试人员来保障。

开发人员完成开发后:

测试人员关注测试用例是否通过。

产品人员确认展现出来的功能是否符合当初的PRD。

业务方确认程序是否符合预期。

举一个我开发项目的例子

一个审批系统

产品的PRD描述了一个三层模型：

流程实例,流程节点,审批任务。流程实例启动创建审批节点，审批节点触发审批任务，任务完成创建下一个节点...。

我是这样做的：

流程实例,审批任务。流程实例启动创建(一批)审批任务,任务被完成后创建后续任务或者流程结束。至于流程节点不存在，不是问题，从任务中提取信息虚拟一个出来。

第一版交付完成。

产品在第一版后追加需求

流程节点可以被非审批人评论。

我....

当时业务方，产品，测试都认为这是一个合理的需求。只有我一脸懵，因为我的程序中没有流程节点这个东西，需求又不能拒绝，无奈给出一个远超他们预期的开发计划。

gap就出在 他们认为流程节点是一个确实存在的东西，而只有我知道这节点是虚拟的，没有标识，不能跟其他信息做关联。

业务建模怎么解决这个黑盒子问题？

DDD引入了业务专家这个角色(在我看来就是业务方，产品)。

1. 假设业务专家听不懂 什么叫类，什么是方法，设计模式&