最近一季度KPI中，增加了一项单元测试覆盖率
在之前工作经历中，也有过类似情况，老板开始关注单元测试情况了，就会加上覆盖率这个绩效指标，不管以前如何应对，还是再次关注了一些对于测试的文章，TDD虽然没有大流行，但这个概念还是常被人提起
这张图是在一篇文章中看到的
好写单测的系统往往比不好写单测的系统更加健壮，如果一个系统大部分代码都可以写无 Mock 单测，那么它看起来就像左图一样，外部调用只是薄薄的一层，可以随意更换。
如果你的系统大部分代码都一定要 Mock 才能测试的话，或者根本无法测试的话，就像右图一样，说明你的业务根本就没有自己的核心逻辑，而是和各种外部调用缠绕在一起
这张图让我有很多的感触，值得整理一下思绪
领域模型
这张图跟整洁架构图特别像
中心是核心的业务逻辑，依赖路径是由外向内，外围千变万化，但内核是不变的
不管是设计，还是编码，亦或是UT，都需要这样的思路；需要高内聚，核心业务代码不能分散，集中，有中心脉络
我们有时过多注重了技术层次，比如MVC，我们更多的是关注各层技术变化速率而分层，而忽略了业务层次变化
结合之前分析的《DDD分层》，也应该是三层，但不是MVC，面是是输入、领域、输出三层，类似端口适配器架构
向心力
这可能跟图的形状有关，因为是圆形。所以想到了向心力这个词，业务逻辑要内聚，单元测试也要内聚，当然了，单元测试的内聚是由于业务逻辑的内聚。
而这种高内聚，正合了向心力。没有向心力就是一群散沙，设计是，架构是，团队亦是
功夫在诗外
以前还写过一篇《功夫在诗外》，为了专业有所精进，就去看了很多专业无关的书，似乎方向搞错了，灵感不是平白无故地出现的，而是长年持续思考累积，再因为偶尔一件诗外之事激发，贯穿了之前的整个思考过程
以前看整洁架构那张图怎么没有如此些感悟呢，因为作为一名程序身在其中，但当看到测试内容时，因不是测试人员，身在事外看事，就有了感悟，所以功夫不能完全花费在诗外，也不能离诗过远，才能带来灵感
