神帥

讀完需要

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 版本的幾個比較大的痛點，以及為什么基于這些痛點去做組件化架構升級的技術決策。

基于 ftl 代碼元素生成比較死板，雖然已經構建了 30 余種代碼元素，支持了 Dubbo, Spring Boot, Cola 架構，但是從架構+框架級別來看，終究無法窮舉所有 Java 企業級代碼元素，比如對于 Spring Cloud 生態的工程架構代碼就需要在代碼生成之后做一定的修改才能做到。

在動態調用時序中無法識別依賴的下游接口,在整個代碼調用流程中無法形成閉環。在調用流程上仍然需要手寫調用下游接口的邏輯。

V2 版本引入的 API 封裝組件為 coderman-utils。coderman-utils 雖然提供了 ResultDataDto,ResultDto 的封裝類，但是如果要讓其他用戶引入或者被企業應用就需要把 coderman-utils 從 codeMaker 中剝離開，降低耦合和依賴程度。

在代碼生成的時候有些工具類是比較獨立的，可以被多個項目引用，但是卻沒有封裝為組件 jar 包，復用能力弱，需要手動復制引入到項目工程中。V2 版本已經默認引入了 AppEventPublisher 等內置的工具類，但是仍然是比較獨立的無法被調用時許圖的內容引入并識別，同時內置的實現是一個個工具類手動注冊的，所以無法滿足更多工具類組件的復用，引入，積累和管理等需求。

從組件級別來說，企業架構應用工程中有自研的技術棧，有封裝的工具組件，有大量的開源組件，這些如果需要被低代碼引入就必然要進行改造，不能一個個的去適配引入。

在領域模型中雖然增加了 extend key 來擴展并銜接領域模型文檔與工程代碼，但是擴展過多就會帶來額外的復雜性并降低易用性，所以從某些方面來說也許控制 extend key 的數量同時用其他的思路方案可能更好。

2

? ?

需求說明

2.1

? ?

總體需求列表

在 1.2.x 系列中按版本算的話，本次組件化架構升級屬于 1.2.2,本版本的特性實現列表也比之前的更多，這里就簡單概括幾個方面吧：

增加 cache,queryobj,feign 接口等代碼元素的生成

增加 springcloud 應用架構的代碼生成

重構包引用邏輯,工具類組件手動注冊邏輯等

組件化動態配置,掃描和引入

工具類手動定義和引入

進行代碼生成的同時構建 API 接口文檔

其他需求特性

下面我重點說一下

2.2

? ?

組件化&配置化需求

上面已經說了當前 V2 版本的一些痛點以及要做組件化的目標，那么這里就需要對組件化的需求稍微細化一下。

支持除了 springboot,dubbo 框架之外的其他類似自研的框架應用代碼生成

需要引入的組件模型可以與低代碼模型協同輔助構建基于調用時序圖的代碼內容

對工具類組件既可以被引入也可以被復制使用，也可以被用于裝飾基本的代碼元素，如抽象的 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

? ?

組件&工具掃描構建使用流程

上面說了組件注冊的流程，這里簡單說一下組件的掃描和構建流程，限于篇幅，我簡單介紹兩個點

組件掃描過程前置與代碼繪制過程，這樣組件的代碼會被引用到

組件被引用的過程有個優先級，優先尋找 plantUML 領域文檔本身定義的類，然后調用時序顯示依賴的業務組件，然后就是全組件集合掃描，如果找不到則對應的調用時序的那一行則繪制代碼行失敗。

3.7

? ?

接口文檔生成

整個實現過程就是將 plantUML 領域文檔的接口聲明構建出來并按接口類寫入到 MD 文檔中，按照簡單的 MD 文檔語法構建接口文檔。

3.8

? ?

重構點

在本次版本中主要有以下幾個重構的內容

READEME.md 文檔重構，同時增加多個相關技術流程文檔和使用文檔，把文檔方面完全補充上來

重構整體 codeMaker 的工程模塊

重構包引用的實現

擴展配置文件

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

? ?

升級改造成果

一鍵式生成業務代碼，業務接口和接口文檔，在構建過程中即可一次性構建領域模型，數據庫模型和調用時序文檔(相當于一鍋出了),讓開發者有更多時間花在方案設計等其他可以提效的問題上。

基本具備框架級，應用級，工具類級組件復用和代碼生成，codeMaker 本身也將邁入企業級低代碼平臺的門檻。

開放低代碼模型和組件化接口模型方便二次開發

8

? ?

未來演進

當前 codeMaker 雖然已經實現了大概的組件化模型和基本能力，但是還沒有進行實際驗證，另外還有一些其他的需求需要跟進，所以借著這個契機發布了 V3 預覽版本，那么在 V3 完整版將把后端涉及到的其他方面完全實現。未來將有以下幾點需要實現來構建 V3 完整版本

選擇一個工具框架組件如 Mybatis-plus 來跟 codeMaker 組件化適配

實現多個模式的參數校驗

支持元數據模式+其他模式生成代碼

細化調用時序圖，讓低代碼更低，生成的代碼盡量接近于 0 代碼。

進行重構支持自定義代碼模板并順利融入代碼生成流程中。

更多相關 codeMaker 項目相關的信息請訪問項目主頁：https://gitee.com/sky-painting/code-maker 也可以關注《神帥的架構實戰》公眾號：

往期推薦

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

干掉visio，這個畫圖神器真的絕了！！！

RedisJson 是什么？比ES快 500 倍？

中國工商銀行的 Service Mesh 探索與實踐

數字化轉型下的銀行云單元架構

漫畫：據說很多搞軟件的羨慕硬件工程師

源三：聊聊注冊中心在螞蟻集團的降本提效之路

聊聊技術人的“績效考核”

總結

以上是生活随笔為你收集整理的天画-codeMaker组件化架构升级实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。