神帅

读完需要

11

分钟

速读仅需 4 分钟

1

背景

1.1

背景说明

在两个月前我扩展了基于调用时序的代码生成，将代码生成的粒度从代码方法级别提升到了代码行级别，从整个迭代过程来看也逐步积累了一些问题，在一些模块设计上实现的不够好，同时没有扩展到 Spring Cloud 体系，另外也在这一段时间重点看了很多低代码的实现，比如易鲸云，简道云，金蝶云等等，我发现如果需要把 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, Spring Boot, Cola 架构，但是从架构+框架级别来看，终究无法穷举所有 Java 企业级代码元素，比如对于 Spring Cloud 生态的工程架构代码就需要在代码生成之后做一定的修改才能做到。

2. 在动态调用时序中无法识别依赖的下游接口,在整个代码调用流程中无法形成闭环。在调用流程上仍然需要手写调用下游接口的逻辑。

3. V2 版本引入的 API 封装组件为 coderman-utils。coderman-utils 虽然提供了 ResultDataDto,ResultDto 的封装类，但是如果要让其他用户引入或者被企业应用就需要把 coderman-utils 从 codeMaker 中剥离开，降低耦合和依赖程度。

4. 在代码生成的时候有些工具类是比较独立的，可以被多个项目引用，但是却没有封装为组件 jar 包，复用能力弱，需要手动复制引入到项目工程中。V2 版本已经默认引入了 AppEventPublisher 等内置的工具类，但是仍然是比较独立的无法被调用时许图的内容引入并识别，同时内置的实现是一个个工具类手动注册的，所以无法满足更多工具类组件的复用，引入，积累和管理等需求。

5. 从组件级别来说，企业架构应用工程中有自研的技术栈，有封装的工具组件，有大量的开源组件，这些如果需要被低代码引入就必然要进行改造，不能一个个的去适配引入。

6. 在领域模型中虽然增加了 extend key 来扩展并衔接领域模型文档与工程代码，但是扩展过多就会带来额外的复杂性并降低易用性，所以从某些方面来说也许控制 extend key 的数量同时用其他的思路方案可能更好。

2

需求说明

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

整体设计方案

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. 扩展配置文件

4

配置化设计

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

4.1

组件化相关配置

1#全局配置-组件化需要的maven repository本地路径,用来扫描依赖的组件jar包2application.maven.repo.path=jar:file:///Users/shenshuai/.m2/repository34#全局配置-代码生成需要的全局组件，框架中间件可以放到全局组件依赖配置里,类似于脚手架,或者自己封装的业务组件框架5application.component.scan.config=dubbo,spring-web,openfeign67#全局配置-自定义的组件扫描bean,defaultCompScanService为codeMaker默认实现支持全局组件的配置，开发者可以参考进行自定义扫描组件实现替代掉默认的8application.component.scan.bean=defaultCompScanService9
10#全局配置-自定义的组件装饰bean,defaultCompDecorateService默认实现支持全局组件的装饰，开发者可以参考进行自定义扫描组件实现替代掉默认的
11application.component.decorate.bean=defaultCompDecorateService
12
13#需要导入的组件列表，多个逗号分割,适用于cola模块下依赖的业务组件包或者对外api接口包，或者cola项目本身已有的代码类,或者其他偏业务的工具类组件等等。
14#如要生成的项目会依赖 infosys-user 服务的api则在这里定义即可。
15applicationType.component.scan.config=apiresult,infosysuser,hutool-core
16
17#应用级组件中间件工具包的组件扫描bean配置
18applicationType.component.scan.beans=appCompScanService
19
20#应用级组件中间件工具包的组件装饰bean配置
21applicationType.component.decorate.beans=appCompDecorateService
22
23#代码工具类注册，项目初始化时可以帮助初始化对应的工具类
24#后面生成代码的时候可以删掉工具类，只专注于生成业务代码
25#格式说明 eg:BaseEvent:core 前面是需要初始化的类，后面是这个类放到哪个模块下
26applicationType.component.init.clazz=BaseEvent:domain,Application:start,BaseController:adapter,SpringApplicationContext:domain,AppEventPublisher:domain

4.2

读写语义配置

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

4.3

接口文档生成配置

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

4.4

sub 子包 request,response 配置

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

5

组件化设计

5.1

框架级组件化

codeMaker 针对 dubbo 和 spring-web 做了框架级组件化配置和装饰实现

5.2

应用级组件化

针对应用级组件则与框架级组件一样，只是用在了代码生成绘制调用时序上了，也可以用来当作框架级组件

5.3

工具类组件化

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

5.4

二次开发

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

5.5

组件复用

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

6

代码生成模式说明

相当于简要的使用手册了，这里从技术角度简单总结一下 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

预览版本架构

7.1

应用架构图

7.2

升级改造成果

1. 一键式生成业务代码，业务接口和接口文档，在构建过程中即可一次性构建领域模型，数据库模型和调用时序文档(相当于一锅出了),让开发者有更多时间花在方案设计等其他可以提效的问题上。

2. 基本具备框架级，应用级，工具类级组件复用和代码生成，codeMaker 本身也将迈入企业级低代码平台的门槛。

3. 开放低代码模型和组件化接口模型方便二次开发

8

未来演进

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

1. 选择一个工具框架组件如 Mybatis-plus 来跟 codeMaker 组件化适配

2. 实现多个模式的参数校验

3. 支持元数据模式+其他模式生成代码

4. 细化调用时序图，让低代码更低，生成的代码尽量接近于 0 代码。

5. 进行重构支持自定义代码模板并顺利融入代码生成流程中。

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

往期推荐

2022年伊始，IT圈还有这些事是你不知道的？

干掉visio，这个画图神器真的绝了！！！

RedisJson 是什么？比ES快 500 倍？

中国工商银行的 Service Mesh 探索与实践

数字化转型下的银行云单元架构

漫画：据说很多搞软件的羡慕硬件工程师

源三：聊聊注册中心在蚂蚁集团的降本提效之路

聊聊技术人的“绩效考核”