天画-codeMaker组件化架构升级实践

一、背景

1.1 背景说明

在两个月前我扩展了基于调用时序的代码生成，将代码生成的粒度从代码方法级别提升到了代码行级别，从整个迭代过程来看也逐步积累了一些问题，在一些模块设计上实现的不够好，同时没有扩展到springcloud体系，另外也在这一段时间重点看了很多低代码的实现，比如易鲸云，简道云，金蝶云等等，我发现如果需要把codeMaker提升到企业级的层次就不能一点点优化，而是要做一个大的架构升级，提高兼容性，扩展性，并在易用性上下功夫。因此准备设计并实现了本次1.2.2版本的组件化架构升级的版本，来解决codeMaker后续迭代的整体架构问题，同时也为codeMaker统一后端Java代码生成做基础。

1.2 V2架构

上面是V2架构的整体架构图，也就是从1.X进化到1.2.X的一个里程碑，因此做了一个架构图，上图可以明显看到codeMaker在V2版本下已经可以生成很多代码元素了。同时codeMaker本身提供的工具能力也初步显现。在1.2.0,1.2.1等版本中主要为了解决将基于plantUML的调用时序图融入到代码生成中。但是遇到一些瓶颈，由于开发工作量比较大，对于时序图本身的解析没有太深，但是很明显的感觉到如果要让调用时序图发挥更大的威力就需要在绘制方法调用时序的时候去引用plantUML领域文档之外的类和服务。在早期codeMaker依赖的工具jar包还是自己封装的，但是明显已经无法满足业务快速生成的需求了。同时跟很多微信群友和大佬讨论技术问题的时候发现组件化这个方向可以帮忙解决codeMaker当前所遇到的问题，因此就着手设计和实现codeMaker的组件化架构升级的需求了。
这里基于动态调用时序图的代码生成技术文章也跟大家分享一下，可以先看一下，避免本篇技术文章看的云里雾里。
codeMaker-支持动态调用时序代码生成

1.3 V2版本痛点

说明:上述架构图中并没有体现出codeMaker动态调用时序技术设计，以及在1.2.x版本的一些新增代码元素，是想在V3版本统一体现的，这里1.2.x的特性都按V2版本算。因此本篇文章算是V2版本组件化架构升级的一个里程碑，基于此达到V3版本的发布特性。这里说一下在V2版本的几个比较大的痛点，以及为什么基于这些痛点去做组件化架构升级的技术决策。

1. 基于ftl代码元素生成比较死板，虽然已经构建了30余种代码元素，支持了dubbo,springboot,cola架构，但是从架构+框架级别来看，终究无法穷举所有Java企业级代码元素，比如对于springcloud生态的工程架构代码就需要在代码生成之后做一定的修改才能做到。
2. 在动态调用时序中无法识别依赖的下游接口,在整个代码调用流程中无法形成闭环。在调用流程上仍然需要手写调用下游接口的逻辑。
3. V2版本引入的API封装组件为coderman-utils。coderman-utils虽然提供了ResultDataDto,ResultDto的封装类，但是如果要让其他用户引入或者被企业应用就需要把coderman-utils从codeMaker中剥离开，降低耦合和依赖程度。
4. 在代码生成的时候有些工具类是比较独立的，可以被多个项目引用，但是却没有封装为组件jar包，复用能力弱，需要手动复制引入到项目工程中。V2版本已经默认引入了AppEventPublisher等内置的工具类，但是仍然是比较独立的无法被调用时许图的内容引入并识别，同时内置的实现是一个个工具类手动注册的，所以无法满足更多工具类组件的复用，引入，积累和管理等需求。
5. 从组件级别来说，企业架构应用工程中有自研的技术栈，有封装的工具组件，有大量的开源组件，这些如果需要被低代码引入就必然要进行改造，不能一个个的去适配引入。
6. 在领域模型中虽然增加了extend key来扩展并衔接领域模型文档与工程代码，但是扩展过多就会带来额外的复杂性并降低易用性，所以从某些方面来说也许控制extend key的数量同时用其他的思路方案可能更好。

二、需求说明

2.1 总体需求列表

在1.2.x系列中按版本算的话，本次组件化架构升级属于1.2.2,本版本的特性实现列表也比之前的更多，这里就简单概括几个方面吧：

1. 增加cache,queryobj,feign接口等代码元素的生成
2. 增加springcloud应用架构的代码生成
3. 重构包引用逻辑,工具类组件手动注册逻辑等
4. 组件化动态配置,扫描和引入
5. 工具类手动定义和引入
6. 进行代码生成的同时构建API接口文档
7. 其他需求特性

下面我重点说一下

2.2 组件化&配置化需求

上面已经说了当前V2版本的一些痛点以及要做组件化的目标，那么这里就需要对组件化的需求稍微细化一下。

1. 支持除了springboot,dubbo框架之外的其他类似自研的框架应用代码生成
2. 需要引入的组件模型可以与低代码模型协同辅助构建基于调用时序图的代码内容
3. 对工具类组件既可以被引入也可以被复制使用，也可以被用于装饰基本的代码元素，如抽象的Base类等。

对于上述相对细化的需求而言，我们需要注意到另外一个潜在的需求，就是灵活性。如果要实现上面的需求就需要做一些配置化，通过配置化可以帮助构建更加灵活生动的代码内容。所以需要在上面的需求实现中构建一些配置项，如初始化组件依赖配置，组件扫描依赖配置，组件扫描实现bean配置等等。

2.3 接口文档需求

这个需求是构建1.2.2版本特性的时候突然想到的，因为既然领域模型文档上已经通过了extend key来扩展出了领域模型的API接口声明，那么基于这些API接口声明则可以很方便的构建接口文档，另外一方面代码生成出来除了修改，调试运行之外还需要编写接口文档，如果这部分工作量能少一些那么这个需求也是非常值得实现的。

2.4 重构需求

在重构方面，我一直想说的就是codeMaker每个版本的迭代都有大量的重构。可能因为代码冗余，因为没有经过详细设计，因为一些写死逻辑的妥协等等。所以重构依然是本版本的重点。在包引用，代码绘制，代码派生工厂，过时配置等方面都需要更好更合适的实现。

三、整体设计方案

3.1 设计思想

兼容并蓄,在codemaker的组件化架构设计中一切业务组件，中间件，脚手架都是组件都是可配置的。

3.2 组件模型

由于需要做组件化，因此这里在设计实现的时候就采用顶层接口设计的模式，确立组件模型并将组件行为定义为顶级接口，让现有的代码生成流程可以很容易的插入组件化模型。以下是设计的三个顶级接口和两个组件模型。

1. 组件顶级接口
   

2. 组件模型
   

3.3 工程重构

浅蓝色模块:codeMaker支持的应用代码生成模块
粉红色模块:codeMaker本身提供的平台能力模块
在之前的微信群推广中有群友就说了codeMaker的文档和流程不够清晰，正好借着这次发版的契机，为自己定下了一个目标就是不急于发布版本，而是先把文档流程补充上来。另外由于codeMaker的项目工程也逐步变多了，所以也将codeMaker-core的代码迁移到了codeMaker-parent模块里，做父子模块与其他代码生成工程区分开来。

3.4 整体使用流程

上图是结合了组件化之后的流程，增加了多个基于组件的配置，因此从代码生成能力上来看又厉害了一些。

3.5 组件&工具类注册流程

这里有必要说明一下组件和工具类如何注册到codeMaker的过程，然后再说如何被codeMaker应用。首先
codeMaker会将组件分为三个等级，一个应用场景。三个等级就是框架级，应用级和工具类组件级别，另外一个场景就是项目初始化构建需要的不仅仅是业务模型代码，还有一些辅助的工具类，所以开发者可以自己定义工具类模板来帮助在项目初始化的时候工具类能被复制到目标项目工程里，这样很多工具类就可以通过模板配置到codeMaker中，将整体的组件能力从单个类到组件本身都可以在codeMaker上被广泛复用。

3.6 组件&工具扫描构建使用流程

上面说了组件注册的流程，这里简单说一下组件的扫描和构建流程，限于篇幅，我简单介绍两个点

1. 组件扫描过程前置与代码绘制过程，这样组件的代码会被引用到
2. 组件被引用的过程有个优先级，优先寻找plantUML领域文档本身定义的类，然后调用时序显示依赖的业务组件，然后就是全组件集合扫描，如果找不到则对应的调用时序的那一行则绘制代码行失败。

3.7 接口文档生成

整个实现过程就是将plantUML领域文档的接口声明构建出来并按接口类写入到MD文档中，按照简单的MD文档语法构建接口文档。

3.8 重构点

在本次版本中主要有以下几个重构的内容

1. READEME.md文档重构，同时增加多个相关技术流程文档和使用文档，把文档方面完全补充上来
2. 重构整体codeMaker的工程模块
3. 重构包引用的实现
4. 扩展配置文件

四、配置化设计

说明:applicationType=cola,springboot,springcloud,dubbo

4.1 组件化相关配置

#全局配置-组件化需要的maven repository本地路径,用来扫描依赖的组件jar包
application.maven.repo.path=jar:file:///Users/shenshuai/.m2/repository

#全局配置-代码生成需要的全局组件，框架中间件可以放到全局组件依赖配置里,类似于脚手架,或者自己封装的业务组件框架
application.component.scan.config=dubbo,spring-web,openfeign

#全局配置-自定义的组件扫描bean,defaultCompScanService为codeMaker默认实现支持全局组件的配置，开发者可以参考进行自定义扫描组件实现替代掉默认的
application.component.scan.bean=defaultCompScanService

#全局配置-自定义的组件装饰bean,defaultCompDecorateService默认实现支持全局组件的装饰，开发者可以参考进行自定义扫描组件实现替代掉默认的
application.component.decorate.bean=defaultCompDecorateService



#需要导入的组件列表，多个逗号分割,适用于cola模块下依赖的业务组件包或者对外api接口包，或者cola项目本身已有的代码类,或者其他偏业务的工具类组件等等。
#如要生成的项目会依赖 infosys-user 服务的api则在这里定义即可。
applicationType.component.scan.config=apiresult,infosysuser,hutool-core


#应用级组件中间件工具包的组件扫描bean配置
applicationType.component.scan.beans=appCompScanService

#应用级组件中间件工具包的组件装饰bean配置
applicationType.component.decorate.beans=appCompDecorateService

#代码工具类注册，项目初始化时可以帮助初始化对应的工具类
#后面生成代码的时候可以删掉工具类，只专注于生成业务代码
#格式说明 eg:BaseEvent:core 前面是需要初始化的类，后面是这个类放到哪个模块下
applicationType.component.init.clazz=BaseEvent:domain,Application:start,BaseController:adapter,SpringApplicationContext:domain,AppEventPublisher:domain

4.3 读写语义配置

#需要在领域文档和调用时序文档中识别的读操作统一语言
applicationType.component.dsl.read=check

#需要在领域文档和调用时序文档中识别的写操作统一语言
applicationType.component.dsl.write=settle,apply

4.4 接口文档生成配置

#是否构建api 文档，否则进行构建,默认构建
applicationType.api.generator=true

4.5 sub子包request,response配置

#是否需要根据该参数设置请求参数的最后一级包名为request,默认false
applicationType.subpackage.request=true

#是否需要根据该参数设置响应参数的最后一级包名为response,默认false
applicationType.subpackage.response=true

五、组件化设计

5.1 框架级组件化

codeMaker针对dubbo和spring-web做了框架级组件化配置和装饰实现
5.2 应用级组件化
针对应用级组件则与框架级组件一样，只是用在了代码生成绘制调用时序上了，也可以用来当作框架级组件

5.3 工具类组件化

在工具类组件上其模型与组件模型和低代码模型是相通的，因此很容易实现工具类组件化

5.4 二次开发

由于对codeMaker整体进行了重构，因此将低代码模型和组件模型以及顶层接口独立出来之后则可以针对某一技术组件或者技术栈做针对性的低代码设计。

5.5 组件复用

从上面的组件构建和使用流程上看，业务组件，技术组件，工具类等都可以在codeMaker上实现复用，很容易基于此对新项目的开发提供帮助，同时在业务组件上，迭代二期，三期的时候可以把业务组件本身的内容打包注册到codeMaker上这样增量迭代则会容易很多。

六、代码生成模式说明

相当于简要的使用手册了，这里从技术角度简单总结一下codeMaker具有哪些代码生成模式。

6.1 纯数据库模式

顾名思义就是支持基于数据模型的代码生成，生成过程很简单，修改配置连数据库启动并访问代码生成API就结束了。这种方式是当前很多低代码都可以实现的。

6.2 动态DDD模式

基于领域模型生成，只生成与领域驱动设计相关的代码元素，比如BO,Factory,Repository,VO,Entity等等，这种模式可以很方便的构建模拟领域模型在代码上的落地情况。并帮助优化领域模型更好的实践DDD，同时这种模式不需要依赖数据库，仅仅是链接了数据库而已。当然这种模式生成的代码只有参考作用。

6.3 数据库模式 + 动态DDD模式

这种模式就是上面两种的结合，将数据库模型与领域代码模型结合在一起就构成了低代码模型，这样的话兼具两者的优势从而在各个层次都变得灵活，让低代码实现上不再变得死板。

6.4 数据库+动态DDD模式+调用时序

这种模式是加入了动态调用时序图文档，将低代码的生成内容从方法级别提升到了代码行级别，如果调用时序文档足够详细可以达到无代码的地步，这样的话生成即可运行是能实现的。

6.5 混合模式

这种混合模式是在V3版本要实现的，目前从1.2.x系列已经完成了基于数据模型和基于领域模型的低代码了，后面需要往API方向实现，也就是面向元数据模式构建低代码，包括不再强行依赖数据库的数据源了。

七、预览版本架构

7.1 应用架构图

7.2 升级改造成果

1. 一键式生成业务代码，业务接口和接口文档，在构建过程中即可一次性构建领域模型，数据库模型和调用时序文档(相当于一锅出了),让开发者有更多时间花在方案设计等其他可以提效的问题上。
2. 基本具备框架级，应用级，工具类级组件复用和代码生成，codeMaker本身也将迈入企业级低代码平台的门槛。
3. 开放低代码模型和组件化接口模型方便二次开发

八、未来演进

当前codeMaker虽然已经实现了大概的组件化模型和基本能力，但是还没有进行实际验证，另外还有一些其他的需求需要跟进，所以借着这个契机发布了V3预览版本，那么在V3完整版将把后端涉及到的其他方面完全实现。未来将有以下几点需要实现来构建V3完整版本

1. 选择一个工具框架组件如Mybatis-plus来跟codeMaker组件化适配
2. 实现多个模式的参数校验
3. 支持元数据模式+其他模式生成代码
4. 细化调用时序图，让低代码更低，生成的代码尽量接近于0代码。
5. 进行重构支持自定义代码模板并顺利融入代码生成流程中。

更多相关codeMaker项目相关的信息请访问项目主页：
https://gitee.com/sky-painting/code-maker
也可以关注《神帅的架构实战》公众号：

​