使用了DDD（领域驱动设计）后，代码有什么不一样呢？这可能是程序员们在接触DDD后最关心的一个问题。这个系列文章会对一些优秀的DDD实例代码进行分析，管中窥豹，略见数斑。这是第一篇。
DDD中程序员最关心的部分
DDD（领域驱动设计）是一个复杂而全面的方法，编码只是最后一步。
但这是程序员最关心的部分，也是被问到最多的问题。
所以计划写个系列文章对一些优秀的DDD实例代码进行分析，希望能解开一些困惑。
IDDD（《实现领域驱动设计》），是最常被推荐的一本书。书中有一个关于构建Scrum管理软件的例子，我们先来分析这个经典的例子的源码（https://github.com/VaughnVernon/IDDD_Samples）。
第一篇先从单元测试和富领域模型说起。
我所目睹单元测试之怪状
关于自动化的单元测试，无数人都心怀向往。
《The Clean Coder》里边描述的测试金字塔给出了单元测试在整个测试中的位置。
经是好经，但大部分时候会被歪嘴和尚给念歪：
- 我遇到的第一个例子，比较普遍，开发人员用JUnit写单元测试，每次本地开发的时候改一改，当main方法用，在构建的时候都把test case都给skip掉
- 我遇到的第二个例子，是曾经有一个质量效能部门推动对单测覆盖率进行考核。结果各个开发团队有苦难言，只有一个开发团队做的比较好，质量效能团队给发了个大奖，后来有人发现这个团队的测试覆盖率高，是因为他们写了一个代码自动生成工具，给每个get/set方法都生成了JUnit测试……质量效能团队被piapia打脸
- 我遇到的第三个例子，是一个 有追求的团队，他们在构建时不skip，但每次做需求的时候，修改单元测试代码的时间甚至会超过了编写正式代码的时间
- 我遇到的第四个例子，是一个更有追求的团队，他们想学习Google、Facebook搞主干开发模式，把CI/CD做的特别好，但自动化测试覆盖率不够还经常跑不通，没有了自动化测试做保障，主干开发也不得不作罢
我在《当我们在谈论单测时我们在谈论什么》里分析过这个问题： “自动化单元测试 = 自动化 + 单元 + 测试”，本质原因是大部分代码“单元化”程度很低，所以，这个前提不具备，是折腾不成功的。
但DDD的富领域模型有助于达成这个前提。
富领域模型为什么有助于单测
DDD的代码组织推荐六边形模型，一个重点是领域层和应用层的分工。
这里有几个有助于用低成本（编写和维护）提升覆盖测试率的条件：
- 领域层里的实体对象不再只是有get/set方法，还有很多业务逻辑。
- 领域实体是没有任何外部依赖的，也就是说，这些业务逻辑都是本地内存中就可以执行的
- 以聚合组织的领域实体内聚性强
- 从图上也可以看出，应用层比较薄，领域层比较厚
我们看看IDDD_Sample这么做了以后，单元测试覆盖率的达到理想的状况吗？
IDDD示例的单测覆盖率统计
首先我们选择agilepm这个模块，看看应用层代码行数和领域层代码行数的对比，看看是否符合领域层比较厚的这个前提。
领域层代码6943行，而应用层只有750行，领域层代码占比达到了90%！！！这个比例是不是和我们平时写的贫血模型代码很不一样？
下面我们看看领域层的无任何外部依赖的单元测试（不需要Mock，不需要准备数据库等）的测试覆盖率：
行代码覆盖率有70%！！！我看了一下，这其中没有被测试到的，是一些equals、get/set方法。除去这些，应该会达到90%，或者继续做的100%也并不难。
总结起来，这个应用的90%的逻辑可以有90%的自动化单元测试覆盖率 —— 不需要mock，不需要依赖数据库、外部中间件、RPC等。
这得益于它使用了富领域模型，而不是贫血模型，得益于其正确地组织了业务逻辑代码。测试覆盖率也从侧面展示了富领域模型到底有多富。
但是先不要急
我最担心的是有人看到这里说：懂了，我们开始搞富领域模型吧！
这可能让你从一个坑里爬出来，接着跳到另外一个坑里。
自动化单测难以推行，是因为“单元化”这个前提不具备。富领域模型可以帮助这个前提的达成。
但富领域模型的前提是什么？已经具备了吗？
且待下回分解。
