DDD提升我的开发效率

2019年参加了"领域驱动设计峰会2019"看到了国内、国外、不同行业在基于DDD的实践分享。

成年热学习的一个特点就是带着自己的经验来思考接收到的内容，那么回顾自己接触DDD有一段时间，将自己的经验和思考作用在项目上，真真切切替换了DDD带给我的提升。

本片内容将不会聚焦在哪些理论上，而是看看那些些提升我开发效率的技术部分（非具体代码的粒度）。

• 充血模型 代替 贫血模型
• Domain + DomainService + ApplicationService
• 基础服务层
• 和业务保持一致
• 统一语言

01 用 充血模型 代替 贫血模型

充血模型的好处是让我最先感觉到收益的地方。

在之前的项目中很多都采用了三层的项目架构设计，短时间内看上去没有什么问题，但是随着项目的进行，Service层变得越来越臃肿，不得不加入其它的约束来让项目结构变得清晰。是的遇到问题、分析问题、解决问题。但是项目毕竟是个团队项目，所以有时候单个人遵守约束很容易，但是让团队都最受这种约束就变的困难的了，所以三层架构在原来的工作中确实带来了一部分问题。

是的，正如上面所言，在简单的场景下，采用贫血模型能够清楚的讲明白的。但是随着业务的丰富，想要通过代码接示业务意图变得异常的困难。

在接触DDD之后，项目开发中，领域模型使用了充血模型，一个领域对象上既包含属性又包含行为，能够保证业务实体为核心的灵活拓展。由采用充血模型避免了面向过程变成面向对象编程。散落在多个Service而不易发现重复的地方业务逻辑能够聚合在领域对象上。

是的，单考虑一个模型，感觉贫血模型会清楚，但是仅仅是感觉，实践之后会发现对充血模型的领域对象所包含的大致内容时序之后，充血模型能够更直白的得到自己期望的和业务相关的信息。

02 Domain + DomainService + ApplicationService

仅仅当领域对象采用充血模型的时候还不够。因为全部代码都放置在领域对象上是不合适的，所以，还需要另外两部分配合，它们是：DomainService、ApplicationService。它们各自承担一部分职责。

ApplicationService接受原始的数据或者Command（命令），它承担着领域实践的调度作用。但是不包含任务业务逻辑，保持对实现细节的黑盒。

DomainService并不是必须的，但是当有些业务逻辑出现在Domain上不合适的时候，我们可以将这部分逻辑放置在DomainService中。这样让Domian保持相对清晰的逻辑，同时不至于逻辑向上泄露到ApplicationService中。

03 基础服务层

和业务关系不大的，但是和技术关系紧密的，全部归为基础服务层。例如：

1. 不含有业务的工具类
2. 项目的Configuration
3. 持久化Repository
4. 和其他服务通信的feign
5. 防腐层ACL

使用基础服务层最明显的感觉就是项目清晰明了，项目包含两部分业务部分、非业务部分。而基础服务层就是非业务的一部分。

举个简单的例子，在做包管理的时候，项目起初顶层有个包：resources、service、utils、config、domain、repository、feign等，随着项目的变化，又增加了新的exception包但是归到顶层包还是某个包下面，这就是纠结了，通过顶层我们看到的更多是技术上面的对包的描述。

采用了基础服务层，之后可以将和业务不想管的技术部分挪到infrastructure中，例如上面的exception包，如果包中描述的技术上需要的异常则直接放置在infrastructure，如果是通过异常表达业务意思，则可以放置在其他合适的包中。

04 和业务保持一致

这里的和业务保持一致，指的是类中的行为，无论是Controller,ApplicationService,DomainService,Doamin都是，通过类名、方法名可以知道这是在处理什么业务。做到开始的时候能够通过方法识别业务并不复杂，但是困难的是持续能够通过类名、方法名来表达业务。

在原来的三层的项目结构中，经过一段时间回头看看项目，想要在代码中找到自己想了解的完整的业务规则，并不是很容。原因就是Service中臃肿，但是在DDD的项目结构中，我们可以相对轻松的找到自己向获取到的信息。这方面我是感觉到阅读代码效率的提升的。

05 统一语言

最后就是统一语言，并不是所有的人都参与到Event Storming中去，但是Event Storming之后，整个团队在项目持续进行的过程中，可以始终围绕着领域模型来进行无歧义沟通。

统一语言是一个持续的过程，当业务发生变更时，领域模型同样需要同步进行变动，进入到新的版本。

基于统一的语言，我们清楚知道要实现什么来满足业务需求，同时也知道领域模型会发生什么变化。当领域模型随着项目的进行逐渐变变得庞大，我们依然知道主线在哪里。从而能够快速的做出做出反应，来应对这种变化。

以为沟通中没有了翻译，所以沟通就不会变的迟钝。

---

参考：
《ThoughtWorks洞见 领域驱动设计》