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

神帅

读完需要

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,本版本的特性实现列表