DDD与不同架构风格下的代码治理

一、背景

1.1 背景

最近我在重构公司的商品中心，目前公司整体在推组件化，因此商品中心也需要实现组件服务的版本，由于是从别的团队里接手过来的，本身功能不是很完善，多人开发，代码风格也不统一，不方便维护和进行组件化。因此我主导了商品中心一期和二期的改造和重构。目前是参考了DDD和COLA的应用架构风格在进行改造。在这个过程中发现代码治理是像是一个新的课题，又像是重构的另一个近义词。细细品来这两者其实还是有点区别的。本文就代码治理和代码重构以及改善代码坏味道的相关问题进行深入讨论。

1.2 代码治理与重构的区别

从字面上看这两个词没什么区别，但是从动机和场景上是有一定的区别的，代码治理不仅包括刚开始建立的工程项目，也包括后期的迭代和维护升级。重构的动机应该是当前已有代码出了一些问题，需要重构和改善。或者说不重构不改善无法完成新的功能。重构基本上是面向代码的，包括前后端，组件，中间件等。代码治理的场景不仅仅包括代码，由于文档，注释等都跟代码强相关，所以代码治理也会包含一些代码的说明性相关的文档内容。重构具有目标性，就是我要改良改善他。代码治理是一个标准的规范工程，其目标是让工程项目永远保持在一个高质量的水平。可以说代码治理包括重构的一些意思和内容。

1.3 代码治理与代码规约的关系

代码治理需要有代码规约的参考和束缚，但是在实际项目中有些规约并不特别强制要求，因此规约在某种程度上是一种软性要求，或者某方面需要规约的强制要求。代码治理就需要在代码规约的基础上进行代码改善和文档改善。没有规约就谈不上代码治理，顶多算是重构，修改。

二、从代码看DDD下的软件复杂度

2.1 业务调用链路

1.整体调用链路太长2.内部调用链路时间太长3.类似功能调用链路重复4.代码调用链路上存在性能和理解上的问题

2.2 代码层次

1.代码层次过多 2.代码层次过少 3.单类单方法在同一层次太长，担任职责太多 4.同一层次的代码随意引用其他层次的接口方法和模型 5.不同风格的代码对代码层次和管理产生冲击

2.3 模型/服务

1.模型的泛化，组合，聚合等关系复杂 2.服务接口和服务类的实现继承，业务逻辑多层次多场景 3.不同层次的模型转换bodo,bodto 4.数据库表到do/entity/rpc层的序列化 5.模型太过精简 6.对接上下游系统，内外部系统太多，代码上强耦合

2.4 进程

1.线程内交互 2.外部业务进程交互 3.中间件进程交互

三、代码治理

3.1 什么是代码治理

字面意思上看就是针对程序员编写的任何代码，脚本进行管理，包括测试代码。代码治理的工作就类似于收拾房间或者收拾厨房，对不同的代码元素做对应的管理，如何命名，怎么用，放在哪里，如何升级，如何换地方，换完地方之后还不影响使用。关于代码治理上更多更深层次的治理还包括，代码的风格，对代码的命名，接口服务的构建，代码包的维护，代码模块的管理等。

3.2 容易产生代码问题的场景

以下是最近在重构商品中心代码的一些感受和总结，包括我最近几年的开发经验。很多时候我也踩过很多坑，包括多人协作的代码风格等问题。

容易产生代码问题的地方 (1).png

3.3 代码治理的好处

为什么要进行代码治理，代码治理与重构给我们的代码和产品带来了多少好处，产生多大收益，这里用思维导图给大家

领域代码治理 (2).png

3.4 治理哪些代码

1.按类型分

需要治理哪些代码.png

2.按框架分

未命名文件 (1).png

3. 按模块职责分

未命名文件.png

3.5 如何治理代码

未命名文件 (3).png

3.6 DDD与代码治理的关系

由于DDD里面涉及到了很多相关的概念和模式这些概念和模式落实到代码上不做维护和管理的话会变得非常混乱。比如在领域层中对于领域实体的命名，对于值对象的区分等。在DDD中的模式和概念可以用很多代码元素去对应，比如领域实体可以用XXXBO。值对象可以用XXXEnum,或者XXXConfig,在基础设施层的模块中可以有XXXAdapter,XXXMapper,XXXRepoImpl等。当领域层或者基础设施层出现了DTO那么这个就存在问题。DTO很容易引起数据模型的混乱，因为假设同一层的模块中你用DTO表示领域模型我用BO表示那就不合理了。因此DDD如果想要在复杂系统中发挥好代码治理和代码规范肯定少不了。不管是什么架构风格或者分层策略，体现在模块和包上面都有自己的职责和上下游依赖关系。因此在DDD实践中如果是大型项目一定建议在代码层面做好代码治理工作，进行多次代码层面的方案评估和codeReview。

四、代码治理场景

4.1 Servlet-JSP时代

此时是相对原始的web后端时代，主要通过servlet+jsp来进行业务操作，这里比较显著的一个特点就是jsp的文件名和servlet的命名会按CURD或者模块去命名。里面的调用链路和相对的业务逻辑都比较乱，比如说可以直接在jsp里面写sql到数据库里面查。另外此时依然需要前端资源辅助，那么jsp的文件里面就会包含前端资源的相关内容。

4.2 Spring-MVC时代

这里的一段时间是SSH的天下，很多web服务和后端服务都是基于SSH实现的，当然也包括一些自研的轮子，主要的问题是这是三大框架的继承，每个框架都有自己的代码特点和对应的职责，所以这里的代码治理调用分层等依然存在很多问题，但是整体来说搞一些中小型的项目，模块多的话可以参考。

4.3 RPC/WEB时代

目前基本上很多大小厂都进入前后端全分离的时代了，此时对于代码治理来说依然不会陌生，后端模块和前端模块的代码层面会更加专业，治理起来也相对容易。但是有些xxx管理系统依然存在前后端放在一个工程里的场景。

4.4 微服务时代

在微服务时代不仅仅包括RPC调用，http调用，消息等情况，微服务包含了很多服务调用的场景，此时的业务和技术比之前都进步不少，而且对于软件复杂度而言，也更复杂了。从端侧到中后台整个调用链路中，涉及到的代码层次非常多，此时对代码进行治理是非常非常重要的，一个核心链路的某一段代码出现潜在的性能问题或者bug都可能引发雪崩式的问题。

4.5 安卓&IOS平台

由于我最近几年主要专注于后端，因此对于这两块的代码治理相关内容不太熟悉，希望读者可以帮忙提供一些内容。

五、总结

就目前而言，只要是人写的代码，只要有需求变化，那么在软件代码层面上就存在代码治理的必要性。整体上看代码治理跟城市治理国家治理类似，不论是对已有的对象进行治理还是改造都有一个主动性的因素在里面，同时要兼顾科学性合理性。另外我也整理了很多关于代码治理，模块治理等相关的其他技术博客链接。主要想表达的意思是代码治理可以帮助我们优化代码工程，提高代码的可读性，降低潜在bug和性能问题。同时可以更好的提升代码的扩展性。代码治理如果做好了，那么在研发效能上也依然有体现。