低代碼平臺設計方案

目標

在線的低代碼開發平臺，用戶在平臺界面經過托拉拽就能完成開發完，線上直接就能使用，不須要學習任何計算機知識，無需關心後端前端數據庫等，只需考慮頁面托拉拽設計，表單設計，流程設計，數據建模等，就能完成一個應用

核心領域劃分

領域:是指根據必定的規則將業務問題限定在特定的邊界內，從而劃分爲一個個範圍

根據雲樞、氚雲等平臺使用文檔中能夠理解到，LowCode平臺的使用流程抽象出來即以下所示

表單設計——>數據建模——>流程設計——>視圖設計

完成之後，用戶根據設計好的流程使用，填寫數據，提交表單，在視圖(後臺)看到相關數據

由此得出四個領域

1. 表單域
2. 數據模型域
3. 工做流域
4. 視圖域

除了工做流域相對獨立，剩下三個域都有必定關係

表單和視圖須要使用數據模型，數據模型是由表單建立，視圖和表單是列表和詳情的關係

各個域的做用和分析

表單域

用戶在客戶端界面經過托拉拽頁面的組件自定義佈局來設計本身的表單，此表單就是指一個html的提交表單

表單由組件構成，1對N的關係，表單實體有表單屬性和配置，每一個組件有本身的屬性和配置。

後端不該該關心表單和組件，只負責考慮用合適的設計去存儲表單和組件的屬性、配置，爲前端提供支持，前端須要考慮如何去運用這些數據。

這麼設計的好處在於，先後基本徹底分離，後端只負責存，前端怎麼用怎麼改由前端本身作主，符合單一職責和開閉原則

表單的構建同時也是初始化數據模型，數據模型是由組件的字段構成的一個數據結構，這部分後端要完成三個目標，

• 數據模型的初始化
• 配置的自動裝配
• 配置的生效使用

這是LowCode的核心基礎之一，決定了LowCode平臺的能用與否，關於數據模型在下文詳細分析。

綜上所述，表單域的需求:

• 前端和後端須要共同定義一種"通用格式"，它的做用有兩個，前端如何能根據這個"通用格式"能方便快速的渲染頁面包括佈局和組件，後端如何根據這個"通用格式"獲取數據模型的字段，舉個例子，最省事的作法就是將整個頁面的HTML代碼保存，前端請求獲取HTML，並渲染。
• 數據模型
• 表單可隨意定製，隨意更改，保存，發佈

數據模型域

表單在完成的時候就會同時初始化完成數據模型，數據模型的字段是來自表單的組件，數據類型就是表單的組件屬性。

數據模型是貫穿整個LowCode平臺使用的對象，全部的操做和配置包括但不限於CURD都是做用於數據模型，因爲表單能夠任意更改組件，因此致使數據模型的成員也是會任意變更。

初始化完成的數據模型，應該內置五種方法:新增，更新，刪除，查詢，列表查詢，也可綁定自定義方法集成服務。

數據模型還容許綁定規則，即觸發事件。例如當對數據模型進行新增的時候，知足A條件的狀況下，觸發A+事件。(參考雲樞和氚雲後，氚雲是不暴露數據模型也就沒有這一個域，而云樞暴露，關於這一點我的認爲優先級不高，不屬於核心，而屬於迭代功能)

數據模型能夠內置權限，指定角色能夠查看哪些數據，同上理由，這也不屬於核心，優先級不高。

數據模型真正的核心點是就是有一套"框架"能高度抽象化模型從而能屏蔽模型差別作到高層次調用，目的只有一個：

內部造成一種機制，以零代碼的方式配置，讓 Web 請求能處理 Action

舉個例子，假設有這種"框架",不管個人數據模型結構如何，一旦建立，就能自動生成對應的curd方法並能夠直接使用，最普通的案例就是代碼生成器。然而這只是最基本的，若是再加上上述的規則，權限，配置等，就將是很複雜的實現。

綜上所述，數據模型的需求:

• 搞個框架?
• 數據模型的初始化
• 內置五種基本方法，並能對數據模型進行操做
• 規則，權限，配置的自動裝配生效使用

視圖域

視圖其實就是一個後臺管理列表頁面。能夠理解爲表單是一個client，視圖是一個後臺系統，提交的表單數據都能在視圖上看到

視圖跟表單不同，視圖的限制比較大，視圖僅僅就是個列表頁，在給定的頁面結構和配置，讓用戶抉擇使用

用戶能夠在視圖頁，指定展現哪些字段，字段是數據模型的子集。數據模型內置的五種方法在視圖的提現就是五個按鈕，查詢按鈕能夠用戶配置查詢條件，可隨時更改。

總結下來，視圖的主要屬性是配置，這一塊的重點跟表單同樣，主要是前端如何將視圖的佈局配置傳給後端，傳一大段html代碼。後端只要數據模型那一塊"框架"搭建的好，這裏就能夠作到以零代碼的方式配置，讓 Web 請求能處理 Action，點擊相應的按鈕就能自動處理。

綜上所述,視圖模型的需求

• 前端和後端視圖頁面的數據流轉
• 內置方法的裝配使用

工做流域

工做流域相比其餘域，是獨立存在的，它所在層級應該是最外層覆蓋的範圍也是四個域裏最大，用戶執行的操做都是在工做流裏的流程。

工做流指「業務過程的部分或總體在計算機應用環境下的自動化」。是對工做流程及其各操做步驟之間業務規則的抽象、歸納描述。

舉個例子，最多見的請假流程，員工A發起請假———>主管B審查經過——>老闆C贊成。這就是一條既定的工做流，是一個既定的"規則"

綜上所述，工做流域的需求

• 後端調研選型一個合適的工做流引擎，投入使用
• 前端將工做流引擎提供的web UI 設計器進行二次開發，符合需求的樣式(工做流的web組件UI太醜

聚合

根據對上述域的分析，能夠總結出來每一個域對應的聚合和實體，如圖所示

紅色標識表示聚合根，白色表示實體，根據這些聚合咱們就能在實際的代碼裏，分好四個模塊，這也是DDD的優點

聚合就是由業務和邏輯緊密關聯的實體和值對象組合而成的，聚合是數據修改和持久化的基本單元，每個聚合對應一個倉儲，實現數據的持久化。

聚合有一個聚合根和上下文邊界，這個邊界根據業務單一職責和高內聚原則，定義了聚合內部應該包含哪些實體和值對象

若是把聚合比做組織，那聚合根就是這個組織的負責人。聚合根也稱爲根實體，它不只是實體，仍是聚合的管理者。

對領域的分析已經肯定了上下文邊界並整理出四個聚合，其中工做流自己就獨立，能夠不算聚合。相關的功能介紹，在領域分析已通過了

1. 數據模型聚合(核心): 聚合根是模型字段。
2. 表單聚合：聚合根是控件。
3. 視圖聚合：聚合根是配置。

實現思路

開頭先說答案:

以mongoDB爲主用來操做數據的CURD，mysql爲輔支持組件配置，仿SpringMVC，servlet實現完成LowCode流程的初始化，配合工做流完成程序的運行

分析提到，表單是可隨意更改組件佈局，這就致使了數據模型裏的字段也是會隨意變更，而數據模型又是整個程序流程中最重要的一環，那不管是出於實現難度、可拓展性、方便性考慮，關係型數據庫如mysql都顯的過重。

廣泛方案都是採用一個表單一個表，存放數據字段，這裏就是涉及到選擇哪一種數據庫，不妨簡單思考一下代碼邏輯實現，

• 當用戶完成表設計之後，代碼須要根據這個表單，建立一個表，用戶更改表單如添加、刪除組件，代碼須要操做數據庫對錶添加、刪除字段；

• 數據模型是要使用的，因爲表單的不肯定性，致使表結構的不肯定性，要求保證能正確的對每一個不一樣的表單完成curd,從這又延申出2種解決方法：

  1. 每次更新表單時，根據表結構動態生成class類從而實例化依賴orm對該類進行curd操做。
  2. 不依賴orm，字段匹配去進行curd操做
• 數據模型的字段還跟其餘配置如規則，權限等捆綁，若是隨意更改，那這些也要想辦法相應的更改

不解決上述3點，LowCode就邁不出第一步，更不用談"框架"。

問題就是如何方便的、拓展性高的、邏輯清晰的解決上述問題

利弊分析

針對上述問題，關係型數據庫和非關係數據庫的優劣分析

• 爲不一樣的表單建立不一樣的表，每一個表有不一樣的字段而且還會隨時更改，針對這一點，很明顯的關係型數據庫弊大於利，若是有N個表單就有N個表，若是這時多表修改表結構會拖垮數據庫。
• 數據模型的curd，因爲模型的多變性就須要考慮不一樣的結構的抽象性，關係型的數據庫有兩種方式：1.動態生成class類 2.依賴SQL用字段匹配。非關係型數據庫：字段匹配直接進行curd就行。
• 與模型相關的配置，這部分變更不頻繁相對有固定的結構，從實現來講關係型的數據庫會更合適。

使用MongoDB來操做數據

關於mongo的介紹這裏不贅述
經過下圖能夠快速瞭解mongo的一些概念

MongoDB 有一個很是突出的特色，即文檔的概念，文檔是一個鍵值(key-value)對(即BSON)。MongoDB 的文檔不須要設置相同的字段，而且相同的字段不須要相同的數據類型，這與關係型數據庫有很大的區別

一個簡單的文檔例子以下：

{"site":"www.baidu.com", "name":"百度"}

集合就是 MongoDB 文檔組，集合沒有固定的結構，這意味着你在對集合能夠插入不一樣格式和類型的數據，好比，咱們能夠將如下不一樣數據結構的文檔插入到集合中：

{"site":"www.baidu.com"} {"site":"www.google.com","name":"Google"} {"site":"www.zhihu.com","name":"知乎","num":5}

這個特性就很是的符合上述表單更改組件致使數據模型結構變動，能很好的包容表單多變的特性，能很好解決表單變更頻繁，
不妨假設一下，若是咱們有請假表單、審批表單等結構不一樣的表單，對應的數據模型也不同，可是mongodb很好的包容了這分差別，這是mongo查詢的用法

db.drivers.find({name: "Xiaose"}) #查找 name 爲 Xiaose 的文檔
db.drivers.find({age:{$gt:20}}) #查找 age 大於 20 的文檔

得益於mongodb結構，咱們不須要關心具體的字段是什麼就能作到將curd抽象，只須要符合作好字符匹配，實現難度低，擴展度高。

同理，對於表單自己這種變更頻繁的，也可也

低代碼框架時序圖

通過上面分析，數據模型的curd已經沒什麼大問題了，剩下的就是在代碼設計層面，如何像spring或者springmvc那樣的框架，作到配置自動裝配，配置自動生效，諸如事件機制，觸發器，監聽器等，如何組合並運用這些通過合理設計作到自動化，達到低代碼或零代碼的目的。

水平不夠，往後待定

代碼設計

根據領域和聚合的分析，按照DDD設計，代碼結構如圖，關於DDD分層概念這裏不贅述。

• application : 應用層，負責編排領域服務
• domain：領域層，領域對象，倉儲，領域服務
• infrastructure：基礎層，提供項目的基礎工具、組件使用
• interfaces：用戶接口層，面向前端的一層

各層流程圖

總結

低代碼平臺是一個大型的工程，不是一蹴而就，其最核心的地方仍是後端如何處理一系列配置從而實現低代碼的目的

核心業務以下：

1. 後端如何作到低代碼開發配置(自動解析數據模型，自動裝配CURD方法，使用規則等)，這是低代碼平臺的基礎
2. 前端和後端的數據交互格式，後端如何告訴前端 界面的設計，前端能展示出來，這是低代碼的門戶
3. 數據如何落地