在大家還沒弄明白信息化和數(shù)字化區(qū)別的時候，數(shù)字化轉型無疑已經成了一個所有企業(yè)都無法避免的大名詞和大問題。
信息化是業(yè)務的數(shù)據化搜集，數(shù)字化則是依托數(shù)據的業(yè)務化創(chuàng)新，低代碼開發(fā)平臺則是一個企業(yè)數(shù)字化轉型必不可少的的基礎架構之一。那么企業(yè)如何選擇自己的低代碼開發(fā)平臺呢？
當然，目前市面上有很多提供低代碼開發(fā)平臺的服務商，主流低代碼開發(fā)平臺我也都逐個試用過，這些平臺的成熟度都比較高，個人也都蠻認可的，但是有幾個問題，不太適合企業(yè)使用，第一：這些平臺無疑都是SaaS的，要想部署到企業(yè)私有云，恐怕需要支付一大筆費用；第二，這些低代碼平臺考慮的通用因素比較多，但是企業(yè)一般都拿低代碼做自己的創(chuàng)新業(yè)務，其實只使用了低代碼開發(fā)平臺的一小部分功能，大部分功能用不上，又不得不學所有功能，學習成本和學習曲線很高；第三，企業(yè)的核心業(yè)余特別復雜，低代碼開發(fā)平臺很難實施出企業(yè)的核心業(yè)務的界面、邏輯，只能依靠靈活的架構定制開發(fā)來實現(xiàn)，具體到企業(yè)技術落地，要么拿不到這些廠商的源代碼，要么這些廠商源代碼特別復雜，改造起來幾乎不可能，所以基于一個簡單低代碼開發(fā)平臺，進行個性化改造，個人認為這是目前企業(yè)上低代碼開發(fā)平臺的一個理性的選擇。
對于低代碼開發(fā)平臺的定位，我個人的總結，40%的非核心業(yè)務的功能，例如基礎數(shù)據的收集、簡單業(yè)務的實現(xiàn)，可以依賴基本的低代碼開發(fā)平臺實施出來；30%獨有的核心業(yè)務功能，依賴靈活的架構定制開發(fā)來解決實際問題；剩余30%復用性比較高的業(yè)務邏輯，可以做成一個一個插件，最開始是個性化定制，然后慢慢通用化，逐步加入到自定義的低代碼開發(fā)平臺內。
那么一個企業(yè)如何自建自己的低代碼開發(fā)平臺呢？一個低代碼開發(fā)平臺，一般包含如下可視化功能：
（1）數(shù)據庫表設計；
（2）前端界面拖拽可視化；
（3）能夠插入邏輯層代碼和業(yè)務規(guī)則；
（4）能夠對接BPM流程引擎；
從上圖中，可以看出，頁面建模，是低代碼開發(fā)平臺的核心技術。市面上開源的也大都是界面建模，包括阿里巴巴旗下釘釘也都開放出自己的源代碼，其它還有百度、騰訊也都有自己頁面建模的解決方案，開源出來，供大家參考。
關于頁面建模的技術選型，與其他企業(yè)開發(fā)技術一樣，無外乎Vue和React、Angular三種的一種，如果團隊中沒有一個偏好，個人建議選擇Vue，因為Vue在國內生態(tài)好，程序員好招聘，價格也不貴。
關于流程建模的選擇，流程引擎無外乎Activiti或者Flowable，他們本是一家的，核心技術人員理念不一致吧，就各自分家了，選擇其中一個即可。關于流程引擎的可視化界面，我看開源絕大部分選擇，都是選擇了bpmn.io，在此基礎上，基于VUE或者React做了二次開發(fā)，界面如下：
個人不喜歡提到業(yè)務流程，就是這種千篇一律的界面，再說這種界面，操作起來，Bug也比較多，所以我個人做了其他選擇，關于低代碼技術架構的細節(jié)，我后續(xù)還會寫文章全部吐出來。
關于低代碼開發(fā)的后端引擎，Java、Spring Cloud、Spring boot則是最佳選擇。我所做低代碼開發(fā)技術架構圖如下：
（待續(xù)…）
版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經查實，本站將立刻刪除。