前言

在低代碼平臺中，如果需要支持復雜模型多數情況下會要求具備模塊級別的源碼導出功能，獨立模塊可以導出為獨立運行的原生代碼方便與業(yè)系統(tǒng)進一步集成。在低代碼平臺相對成熟的今天，這一功能也成為了絕大多數商業(yè)企業(yè)級低代碼平臺的必備功能，本文將從模塊代碼導出的角度來聊一下，低代碼平臺的代碼出碼設計。

一，低代碼平臺常用出碼模式

在用戶完成基礎的視圖設計以及應用邏輯編排后，通常需要將業(yè)務設計通過特定的方式轉化為可執(zhí)行的代碼及配置以便于仿真測試或者直接交付部署應用。通常這個過程有以下幾種方式：

（1）模板模式(直接出碼為可執(zhí)行原生代碼)

早在低代碼相關技術誕生以前，代碼生成模式就風靡于架構設計圈子。由架構師確立技術路線和代碼結構，通過framake等模板語言將數據庫或者通用配置批量的生成基礎代碼，然后交由程序員進行二次加工。

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

這種方式優(yōu)點是：

簡單易操作，一個稍有經驗的高級程序員即可完成整套的基礎模板設計，在經過模板輸出后可以大幅降低普通程序員的勞動強度。

但缺點也很明顯：

首先由于模型設計過程中過于簡單，缺少元數據以及元元數據屬性的支撐，在代碼生成時需要更高級的屬性支持時只能在模板中去豐富，這就造成代碼模板會被嚴重污染大幅降低通用性，在真實使用過程中往往會出現一個項目一套模板，甚至一個程序員都有一套自有模板的囧局。這使得項目可維護性大幅降低，另外代碼在生成后，多數情況下還需要進行一些二次補充和修改。這個些過程中通常是不可逆的，這使得代碼生成只能在項目初始構建的時候使用，對于功能擴展或者代碼重構都無法發(fā)揮其應有的作用。

小結：

單純的代碼生成模式如果純粹作為程序員或者微型項目組，作為代碼工具使用尚可，在早期低代碼平臺中也比較常見于各種行業(yè)模板等應用，但隨著技術進步，這種方式正在逐步被淘汰。

（2）引擎驅動模式（出碼為DSL）

引擎驅動模式最早來起源于“中間件”設計，其設計目的是將大量具有通用意義的業(yè)務邏輯進行抽象包裝，提供獨立的數據模型業(yè)務驅動模式再根據業(yè)務特性，抽象出特定的DSL業(yè)務描述語言，例如：流程語言BPEL, 報表中延續(xù)的EXECL公式，數據庫的SQL語言等等。用戶通過DSL語言來描述業(yè)務結構以及數據信息，然后將DSL交由引擎去執(zhí)行，從而有效實現業(yè)務與代碼的解耦。這種技術在低代碼平臺中應用還是比較廣泛的，在企業(yè)級低代碼平臺應用中更是標配。

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

結構組成

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

出碼實施過程

引擎模式優(yōu)點：

引擎模式是將業(yè)務模型輸出為“DSL”這種中間語言，這種方式很好的解決了模型的二次維護與可逆性輸出，在通用性的功能以及技術細節(jié)處理也相對更完善，能給直接用戶帶來更好的使用感受，在項目的重構以及后期維護方面也有不錯的表現。

引擎模式缺點：

（1）易用性缺失，對使用者技術要求太高：

引擎模式有著諸多的優(yōu)勢，但在低代碼平臺除了需要強勁的功能支持以及擴展性支持外，還需要兼顧其易用性，對于低代碼平臺的核心用戶主要還是定位在泛開發(fā)者而非專家型程序員。多引擎的設計會隨著引擎細分越多、功能越強大、對于開發(fā)者而言所需的專業(yè)領域也會越寬泛。集成二次開發(fā)要求也會越來越強。而多引擎模式下所推崇的中臺模式、APAAS平臺初衷雖是為了更好的解耦應用實現微服務架構。但在一定程度上與低代碼平臺泛開發(fā)者定位是背道而馳的。往往在企業(yè)應用中往往是一旦建立起來中臺，APAAS應用就成為了巨無霸的存在，使得業(yè)務缺少靈活性，技術架構更是僵硬不堪。

（2）構建過程復雜，不適合簡單應用

引擎模式下，業(yè)務功能拆分會比較細，這種拆分對于構建復雜應用是有益處的，但在日常企業(yè)應用開發(fā)中在大多數的應用功能，往往是類似于：“實驗數據上報”、“儀器設備管理”等等只在相對封閉的環(huán)境下使用的小功能。對于這種簡單應用，引擎的功能就會顯得過于強大。而其中包含的隱形規(guī)則和設計要求更使得普通開發(fā)者無所是從。

（3）引擎擴展困難

業(yè)務應用往往是復雜多變的，對引擎的要求也會多種多樣，有的時候功能強大和業(yè)務實用是兩個概念。單純依靠引擎功能的無限窮舉擴充來達避免業(yè)務代碼對引擎的侵入有的時候會適得其反。適當的外延API允許開發(fā)者進行深度的調用開發(fā)是大多數引擎的策略。但要使用好這一策略其實并不容易，需要開發(fā)者提出了對引擎結構具備相當的熟練程度。者一點往往成為引擎模式下最大的攔路虎。

（3）DDD領域驅動設計（出碼為DDD領域設計驅動語言）

領域域驅動設計(簡稱 ddd)概念來源于2004年著名建模專家Eric Evans 發(fā)表的他最具影響力的書籍:《領域驅動設計——軟件核心復雜性應對之道》（Domain-Driven Design –Tackling Complexity in the Heart of Software），簡稱Evans DDD，在DDD中涵蓋了業(yè)務需求分解方法，項目工程管理方法，以及其通過倉儲庫、領域模型等一些列概念的定義來達到其高聚合、低耦合的設計目的。

域驅動設計早期是作為軟件架構設計的基礎理論模型，是架構師的理論必修課。但在低代碼應用中，根據DDD驅動設計模型的低代碼工具則使得普通的開發(fā)者也可以設計出優(yōu)秀的軟件作品。這使得支持DDD理論模型成為了新一代的低代碼平臺理論標桿。而一系列領域模型工具的出現也大幅的降低了領域驅動設計的門檻。

領域建模模型：

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

DDD領域驅動模式優(yōu)點：

（1）簡單業(yè)務與復雜引擎業(yè)務統(tǒng)一模型支持

領域驅動模式，是代碼生成與引擎模式的加強版。在領域驅動模型中各個引擎的功能，通過通用域、支撐域等領域模型進行了更高階的包裝與描述。開發(fā)者不再單獨的圍繞著獨立的引擎API來完成開發(fā),而是統(tǒng)一到領域服務與領域事件中使用統(tǒng)一的領域工具完成配置應用，而簡單單一的業(yè)務模型也可以通過倉儲模版構建復合領域模型聚合實體庫，最終統(tǒng)一到獨立的自定義用戶域服務，開發(fā)者在基于領域模型時可以有機的將二者串聯起來。的以便于業(yè)務邏輯與具體實現的分離。而統(tǒng)一的語言環(huán)境支持則允許領域服務可直接觸及各引擎的DSL規(guī)則，方便于在領域事件中有機的完成各引擎的協(xié)同工作。

（2）以業(yè)務應用為中心建模高聚合應用

領域建模設計理念上是以具體的“業(yè)務模型”為基礎的，其對應的出碼輸出物也是可直接運行的業(yè)務代碼。這一點得益于其高聚合的設計，但同時也為低代碼平臺向無代碼過渡提供了有力的建模理論支持與技術支撐。

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

（3）模塊間的低耦合設計

DDD領域驅動設計在強調業(yè)務主導的同時，也更注重元圍繞著業(yè)務主體流程及數據的元數據以及元元數據的支持，在主體業(yè)務之外采用元數據以及元元數據模型來描述業(yè)務源本身關聯的事件、動作、交互展現等等。這使得業(yè)務本身的隔離性會更優(yōu)秀，業(yè)務模塊的之間的關聯關系也更清晰。在設計業(yè)務關聯以及實現時只需要關心業(yè)務本身的關聯即可，而對于其他的事件，展現交互等統(tǒng)一作為元數據與元元數據處理實現解耦應用。

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

元元數據配置

低代碼平臺業(yè)務模型設計（低代碼平臺業(yè)務模型設計方案）

DDD領域驅動模式缺點：

領域驅動設計高度抽象隔離了業(yè)務實現，但其作為一個新型的設計模式。對應的工具以及開發(fā)者生態(tài)還相對匱乏，對于大多數已經通過原生代碼完成集成的業(yè)務模塊以及基于引擎DSL語言的業(yè)務模型而言，元數據以及元元數據的剝離還需有待時日。

二，OneCode低代碼引擎出碼設計

OneCode低代碼引擎是一款基于DDD驅動設計的通用低代碼引擎。OneCode 采用Java作為原生語言，通過Java元數據注解方式，實現了一套完整通用領域驅動元數據模型。并且針對領域模型的元數據以及支撐元數據應用的元元數據提供了完整的配置管理以及元數據出碼設計。開發(fā)者只需要引入OneCode元數據注解包，添加相應的元數據注解即可通過OneCode低代碼引擎渲染輸出為領域模型應用。