DDD之代码架构

点击↑上方↑蓝色“编了个程”关注我~

每周至少一篇原创文章

这是本公众号的第 33 篇原创文章

荒腔走板

这是一篇迟到的文章。这其实是我写DDD的第四篇文章。去年11月份左右我在个人网站上写了三篇关于DDD的文章，都是比较偏战略部分的。那个时候我还在一个正在使用DDD的项目上，也是我第一次真正开始深入使用DDD。

DDD的前3篇文章

后来有收到读者催更的留言。其实那个时候也在陆续写文章，DDD第四篇想写战术模式方面的文章，尤其是代码架构。但一直觉得自己这方面还需要再学习修炼一下。且之前在项目上实践DDD，落地到代码上还是遇到了一些问题的，我也在思考怎样才能更好地让DDD在代码层面落地。

❝

本文适合于对DDD战术模式有一定了解的读者。

❞

从复杂性谈起

要聊架构问题，其实要先明白架构想要解决的是什么问题。我认为代码架构主要解决的是两个问题：程序的复杂性和编程的复杂性。

依赖混乱导致了程序复杂

程序的复杂性，指的是程序里分层或抽象不清晰，导致依赖关系比较乱。这里的“依赖”其实可以比较简单地理解为，A使用了B。如果删除了B，A就不能继续正常工作了。AB可以指的是类、模块、分层等概念。

经过了很长一段时间的发展，现在软件界已经能够总结出一些比较好的设计模式、分层架构、甚至是基于maven/gradle等构件工具的模块化、代码分包、甚至是微服务拆分等手段，来尽量减少彼此之间的依赖，架构的本质就是要尽量做到“高内聚，低耦合”。

然而架构很难完美。现在市面上绝大多数后端Web项目用的是“三层架构”（或者更多层，但本质上是差不多的），即controller -> service -> dao。其中controller层和dao层处于依赖关系的两端，且职责比较清晰，一般不会有什么太大的依赖复杂性。但service层就不一样了，它承载了所有的主要逻辑，彼此之间相互调用是很正常的一件事，所以service层的依赖关系很容易变得错综复杂。这就会导致软件到后面会变得越来越难以维护。

DDD结合整洁架构可以让依赖变得清晰，比三层架构有更好的“高内聚，低耦合”特性。

技术和业务耦合导致了编程复杂

编程这件事为什么复杂？为什么只有程序员能做，甚至初级程序员还做不好？不就是CRUD（增删改查）加if-else吗？

其实主要原因是编程这件事，有很多技术上的东西。可能要与数据库打交道，可能会发送消息，使用缓存，处理并发，处理失败、超时问题等等。这些事情其实都是与业务逻辑无关的，可以说是纯技术上的东西。

而业务逻辑，才是真正的CRUD加if-else。「开发人员在写业务逻辑的时候，像个把业务语言翻译成代码语言的工具人，其他时候我们才是工程师」。我们很多bug，可能并不是技术层面的bug，而是由于开发和测试没有足够了解业务造成的，遗漏了业务上的某些点，产生了业务上的bug。

在三层架构，往往技术和业务是耦合粘连在一起的，至少代码层面上很难把它们分开，很难单独把“业务”方面的代码抽离出来。

但DDD可以，DDD可以把业务全部内聚在领域层，且领域层不依赖其它任何东西，只有最纯粹的业务。那我们是不是甚至可以把这一层的user case和单元测试、甚至是实现代码都给业务同学（或者是领域专家