产品代码都给你看了，可别再说不会DDD系列（四）代码工程结构

　　这是一个讲解DDD落地的文章系列，它以一个真实的并已成功上线的软件项目为例，系统性地讲解DDD在落地实施过程中的典型实践，以及在面临实际业务场景时的各种取舍。
　　本系列包含以下文章： DDD入门 DDD概念大白话 战略设计 代码工程结构（本文） 请求处理流程 聚合根与资源库 实体与值对象 应用服务与领域服务 领域事件 CQRS 案例项目介绍
　　既然DDD是＂领域＂驱动，那么我们便不能抛开业务讲技术，为此让我们先从业务上了解一下贯穿本文章系列的案例项目 —— 码如云（不是马云，也不是码云）。如你已经在本系列的其他文章中了解过该案例，可跳过。
　　码如云是一个针对二维码场景应用的SaaS软件平台，采用＂一物一码＂的业务模式，可以为每一件＂物品＂生成一个二维码，并以该二维码为入口展开对＂物品＂的相关操作，典型的应用场景包括固定资产管理、设备巡检以及物品标签等。
　　在使用码如云时，首先需要创建一个 应用 ，一个 应用(App) 包含了多个 页面(Page) （也可称为表单），一个 页面 又可以包含多个 控件(Control) （比如单选框控件）。 应用 创建好后，可在 应用 下创建多个 实例(QR) 用于表示被管理的对象（比如机器设备）。每个 实例 均对应一个二维码，手机扫码便可对 实例 进行相应操作，比如查看 实例 相关信息或者填写页面表单等，对表单的一次填写称为 提交(Submission) ；更多概念请参考码如云术语。
　　在技术上，码如云是一个无代码平台，包含了表单引擎、审批流程和数据报表等多个功能模块。码如云全程采用DDD完成开发，其后端技术栈主要有Java、Spring Boot和MongoDB等。 代码工程结构
　　在码如云，我们经常会受邀去给其他公司或组织分享DDD的落地实践经验，分享期间听众一般会问很多问题，被问得最多的反倒不是限界上下文如何划分，聚合如何设计等DDD重点议题，而是DDD工程结构该怎么搭，包该怎么分这些实实在在的问题。
　　事实上，DDD并未对工程结构做出要求，在码如云，我们结合行业通用实践以及自身对DDD的认识搭建出了一套适合于自身的工程结构，我们认为对于多数项目也是适用的，在本文中，我们将对此做详细讲解。
　　在上一篇战略设计中我们提到，码如云是一个单体项目，其通过Java分包的方式划分出了3个限界上下文，即3个模块。对于正在搞微服务的读者来说，可不要被＂单体＂二字吓跑了，本文所讲解的绝大多数内容既适合于单体，也适合于微服务。
　　以上是码如云工程的目录结构，在根分包 src/main/java/com/mryqr  下，分出了core  、integration  和management  3个模块包，分别对应＂核心上下文＂、＂集成上下文＂和＂后台管理上下文＂，对于微服务系统来说，这3个分包则不存在，因为每个分包都有自己单独的微服务项目，也即DDD的限界上下文和微服务存在一一对应的关系。与这3个模块包同级的还有一个common  包，该包并不是一个业务模块，而是所有模块所共享的一些基础设施，比如Spring的配置、邮件发送机制等。在src  目录下，还包含test  、apiTest  和gatling  三个目录，分别对应单元测试，API测试和性能测试代码。此外，deploy  目录用于存放与部署相关的文件，doc  目录用于存放项目文档，gradle  目录则用于存放各种Gradle配置文件。分包原则：先业务，后技术
　　在以上提及的各种模块包中，程序员们最为关注的估计是 core  包之下应该如何进一步分包了，因为core  是整个项目的核心业务模块。
　　在做分包时，一个最常见的反模式是将技术分包作为上层分包，然后在各技术分包下再划分业务包。DDD社区更加推崇的分包方式是＂先业务，后技术＂，即上层包先按照业务进行划分，然后在各个业务包内部可以再按照技术分包。
　　在码如云的 core  模块包中，首先是基于业务的分包，包含app  、 assignment  等几十个包，其中的app  对应于应用聚合根，而assignment  对应于任务聚合根，也即每一个业务分包对应一个聚合根。在每个业务分包下再做技术分包，其中包含以下子分包：command  ：用于存放应用服务以及命令对象等，更多相关内容请参考应用服务与领域服务；domain  ：用于存放所有领域模型，更多相关内容请参考聚合根与资源库；eventhandler  ：用于存放领域事件处理器，更多相关内容请参考领域事件;infrastructure  ：用于存放技术基础设施，比如对数据库的访问实现等；query  ：用于存放查询逻辑，更多相关内容请参考CQRS。
　　在这些分包下，可以根据实际情况进一步分包。
　　这种＂先业务，后技术＂的分包方式有以下好处： 业务直观：所有的业务模块被放在一起，并且处于一个分包级别中，让人一眼即可全景式地了解一个软件项目中的所有业务。事实上，Robert C. Martin（Bob大叔）提出了一个概念叫尖叫架构（Screaming Architecture）讲的就是这个意思。尖叫即＂哇的一声＂的意思，比如当你看到一栋房子时，你会说＂哇，好一栋漂亮的房子！＂，也即你一眼就能识别出这是一套房子。 便于导航：当你要查找一个功能时，你首先想到的一定是该功能属于哪个业务板块，而不是属于哪个Controller，因此你可以先找到业务分包，然后顺藤摸瓜找到相应的功能代码。 便于迁移：每一个业务包都包含了从业务到技术的所有代码，因此在迁移时只需整体挪动业务包即可，比如，如果码如云以后要迁移到微服务架构，那么只需将需要迁出的业务包整体拷贝到新的工程中即可。
　　在以上子分包中， domain  分包应是最大的一个分包，因为其中包含了所有的领域模型以及业务逻辑。在码如云项目的app  业务包下，各个子分包所包含的代码量统计如下：
　　可以看到， domain  包中所包含的代码量远远超过其他所有分包的总和。当然，我们并不是说所有DDD项目都需要满足这一点，而是强调在DDD中领域模型应该是代码的主体。
　　接下来，让我们来看看各个子分包中都包含哪些内容，首先来看 domain  分包：
　　在 domain  分包中，最重要的当属App  聚合根了，除此之外还包含领域服务AppDomainService  ，工厂AppFactory  和资源库AppRepository  。这里的AppRepository  是一个接口，其实现在infrastructure  分包中。基于内聚原则，有些密切联系的类被放置在了下一级子分包中，比如attribute  和page  分包等。值得一提的是，用于存放领域事件的event  包也被放置在了domain  下，因为领域事件也是领域模型的一部分，不过领域事件的处理器类则放在了与domain  同级的eventhandler  包中，我们将在 领域事件中对此做详细讲解。
　　command  包用于放置应用服务以及请求数据类，这里的＂command＂即CQRS中的＂C＂，表示外界向软件系统所发起的一次命令。
　　在 command  包中，应用服务AppCommandService  用于接收外界的业务请求（命令）。AppCommandService  接收的输入参数为Command对象（以＂Command＂为后缀），Command对象通过其名称表达业务意图，比如CopyAppCommand  用于拷贝应用（这里的＂应用＂表示业务上的应用聚合根），CreateAppCommand  用于新建应用。
　　eventhandler  用于存放领域事件的处理器类，这些类的地位相当于应用服务，它们并不是领域模型的一部分，只是与应用服务相似起编排协调作用。
　　infrastructure  用于存放基础设施类，主要包含资源库的实现类：
　　query  用于存放与数据查询相关的类，这里的＂query＂也即CQRS中的＂Q＂，我们将在本系列的CQRS中对此做详细讲解。
　　自动化测试
　　自动化测试包含单元测试、API测试和性能测试。在API测试中，数据库和消息队列等基础设施均通过本地Docker完成搭建，测试时先启动整个Spring进程，然后模拟前端向各个API发送真实业务请求，最后验证返回结果，如果遇到有需访问第三方系统的情况，则通过Stub类进行代替。码如云采用的是 ＂API测试为主，单元测试为辅＂ 的测试策略，其API测试覆盖率达到了90%，所有的业务用例和重要分支都有API测试覆盖，单元测试主要用于测试领域模型，对于诸如应用服务、Controller以及事件处理器等结构性设施则不作单元测试要求，因为这些类并不包含太多逻辑，对这些类的测试可以消化在API测试中。 总结
　　本文主要讲解了DDD代码工程的典型目录结构，我们推荐通过＂先业务，后技术＂的方式进行分包，这样使得项目所体现的业务更加的直观。此外，在DDD项目中，领域模型应该是整个项目的主体，所有的领域对象和业务逻辑均应该包含在 domain  包下。在下文请求处理流程中，我们将对DDD项目中请求处理的全流程进行详细讲解。