领域驱动设计DDD落地实践系列：工程结构分层

引言

前面几篇文章中，笔者给大家阐述了 DDD 领域驱动设计的三大过程，重点围绕如何通过战略设计与战术设计进行 DDD 落地实践进行了详细的讨论，但是还没有涉及到工程层面的落地。实际上所有的这些架构理论到最后都是为了使得我们代码结构更加清晰，从而开发出 bug 少、扩展性强、逻辑清楚的应用。因此本文就是为了解决 DDD 领域驱动落地实践最后一公里问题，将我们分析出来的领域模型通过与工程结构的映射实现真正的落地。

DDD 领域分层

当我们完成领域模型构建之后，我们需要先确定下微服务内部的领域分层结构，因为这个领域分层的好坏直接决定了我们微服务的工程结构是否合理，调用逻辑是否清晰。而这些领域模型都需要映射到实际的代码，我们开发的代码到底应该放在哪一层，放在哪些目录中，都需要依托于领域封层的结果。但是真正的领域驱动设计在怎么规范代码结构上面实际也没有具体的规范，因此我们需要根据自己的实践经验以及思考进行划分。

分层的目的实际上就是让各层的逻辑可以分工协作、各司其职，避免不必要的代码互相污染。同时结构清晰的分层结构也比较便于后期的重构以及拆分或者合并，实际上也是一种在为未来可能存在的变化节省研发成本。

这里需要说明的是，在传统的领域分层中，是将基础设施层作为其他三层的依赖的，但是实际上这种方式是有问题的。为什么这么说呢？因为如果我们真的按照用户接口层、应用层以及领域层都依赖基础设施层的话，那基础层就成了最核心的层级了，但是实际上领域层才是真正的核心，这显然违背了 DDD 以领域为核心的设计思想。因此我们使用依赖倒