基于低代碼PaaS對于對象、、、模型及組建關系的全新解析

2022-09-27

低代碼技術與組件化趨勢之間有著天然的基因級的融合優勢，，，這種融合來自于共同的解耦到封裝的構建思路。但是，，，如何嚴謹規范地做好業務解耦，，，如何全面實現組件和業務之間的準確匹配，，，如何對于對象的定義和層級進行劃分，，，對象、、、模型、、、組件三者之間的關系如何界定，，，目前業界缺乏統一完整科學規范的方法論。本文就試圖對上述問題予以探討。

可組合的業務(Business Composability)已經被Gartner倡導認為是應對業務創新中不確定性的最佳策略和方法，，，其核心思想是將具備業務共性的業務元素沉淀形成組件化模塊化，，，以便快速地搭建新的應用。Gartner為我們揭示了業務中、、、后臺的拆分要遵循的三條核心原則：一是可復用，，，二是跨系統的共享，，，三是聚焦業務邏輯而非業務執行。

業務流程的抽象和業務功能的拆分為針對領域模型為核心的驅動設計以及服務化(微服務)在平臺功能抽象拆分提供了相對值得借鑒的思路，，，催化了以業務功能細分作為域劃分的依據的組件化方案，，，主要訴求是在細分的業務功能組件服務基礎上，，，能按需快速靈活地組合，，，從而支撐不同的業務模式，，，提供業務敏捷性，，，支撐業務創新求變。

而且，，，這種靈活組合的另外一個容易被忽略的潛在價值在于試錯成本的最小化。業務創新并不一定總是成功的，，，如果拆除一個失敗的創新業務，，，組件化的架構也不會影響其他正常業務，，，其業務價值就是極大的打開了業務創新的施展空間而無需擔心高昂的試錯成本，，，這就使得通過新一代組件化架構對類似ERP、、、PLM等大型傳統應用予以重構帶來可能。

看起來前景無限光明的業務組件化，，，其前提條件毫無疑問是組件對業務的支撐能力，，，而這種能力，，，就來自于對業務科學規范的解耦和映射的方法。

業務元素應該包括業務對象、、、業務要素、、、業務邏輯和業務規則等，，，將業務元素封裝在組件中的核心技術就是對象建模。應該說，，，對象建模本身并不是高不可攀的技術，，，通過各維度的數據從邏輯和屬性上對業務實體做出科學準確的表達是可以實現的。這其中最大的挑戰在于對于對象的定義和分級，，，由此梳理清晰對象的邊界和組件之間的協作模式，，，為后續的敏捷開發奠定基礎。顯然，，，混亂的業務組件必然會對整體應用搭建造成隱患，，，如果對象定義不夠清晰，，，模型和組件層級沒有準確匹配業務域和業務能力的支撐，，，對應用開發將是災難性的。

所以，，，對象建模方法論就顯得尤為重要。

真正的難度在于如何準確地區分并定義不同層級的對象、、、組件形成完整的與業務的對應關系，，，這當然需要科學方法論的指導。這個方面，，，傳統企業EA架構理論中從業務模型到數據模型的嚴謹規范的設計思想以及數據治理思想中概念數據模型等理論值得借鑒。以下舉例說明。

在軌道運維業務中，，，我們形成了完整的從業務能力（業務域）-業務流程-業務實體-數據模型的分析梳理過程。軌道運維業務能力如下圖所示：

匹配業務能力要求的業務流程如下圖所示：

OKPAY錢包

在上述業務流程涉及到的業務實體如下圖： OKPAY錢包

最后對應到真實發生的數據實體上，，，如下圖：

梳理完所有的業務流程、、、業務實體、、、數據實體后可以將對象作出根據不同業務域的清晰的層級劃分，，，如下圖： OKPAY錢包

最終形成完整統一的軌道運維概念數據模型，，，如下圖： OKPAY錢包

可以看出，，，這是一個完整的從具體到抽象的高度提煉概括的過程，，，整個過程緊密貼合實際業務，，，全面客觀地對應業務實體和業務對象，，，最終實現數據對業務的準確映射。

上述這個過程也是我們對象定義和建模、、、組件定義和分級、、、模型定義和分級的核心依據！

例如我們對“鋼軌”這個實體對象做建模，，，通過9個邏輯維度、、、63個邏輯要素做好元數據定義和約束，，，并形成關于“鋼軌”這個對象組件，，，由此來支撐所有需要“鋼軌”這個組件的領域模型建設。

而“鋼軌”、、、“焊縫”、、、“扣件”、、、“軌枕”、、、“道床”、、、“道岔”、、、“伸縮調節器”、、、“接觸軌”、、、“軌道附屬設施”等所有的對象完成建模和組件化后就可以完成“基礎設備信息”這一業務域的局部領域模型建設，，，這個模型對應的就是數據模型中的一級主題域，，，也可以對應業務模型中的一級業務域。而所有的局部領域模型建設完成，，，就可以實現針對全業務的領域模型。

對象、、、組件和模型其實都是有層級的，，，是必須嚴謹對應到業務上的，，，也只有這樣的嚴謹，，，才能將業務中那些最難發現的、、、隱藏在實際業務中的業務邏輯和業務規則完整繼承下來。并且，，，這種分析和梳理的過程，，，也是對IT核心資產的完整繼承。IT的核心資產，，，其實應該是現有系統中已經在運行、、、并證明對業務有真實支撐能力的業務模型和數據模型，，，而上述解耦和封裝的過程，，，是完全基于對業務模型和數據模型科學嚴謹的學習和理解的過程。

以上是方法論思想的論述，，，更為技術角度的解讀是從平臺業務系統的邏輯模型到物理模型的直接映射為造成問題的主要因素來出發的。既然物理模型的變更是平臺不穩定的動因，，，那么我們是否能通過解耦業務邏輯模型和物理模型的映射關系來嘗試解決這個問題呢？

基于上述的事例，，，我們需要對業務進行建模，，，對業務進行抽象，，，定義出業務邏輯模型，，，然后對模型進行二次抽象，，，定義出邏輯模型的定義數據，，，實現業務模型的數據化，，，即模型的元數據(The Metadata of the Logic Model)，，，將模型結構存儲為數據，，，而不是直接對應的物理存儲結構。其次根據定義出的元數據進行統一抽象，，，形成元數據邏輯模型。將元數據邏輯模型映射到元數據物理模型，，，對應實際存儲結構。

通過對業務模型的變更形成對元數據層的數據變更，，，而不是物理結構的變更，，，從而實現業務邏輯模型同物理模型的解耦。當然反過來，，，由于縱向功能細分，，，業務功能域增多，，，整個業務鏈條上的咬合點越來越多，，，

于是，，，可以得出的結論是，，，最小業務組件顆粒其實就是描述最小業務實體所對應的業務對象，，，而組件要素就是描述最小業務對象所對應的元數據！而將該元數據所對應的所有業務邏輯要素（屬性和規則等）同業務對象一起做好封裝就形成了最小業務單元組件！

這其實就是傳統的業務邏輯模型的實現過程的組件化。將某一業務域所有業務組件做有機整合，，，結合流程模型、、、報表模型、、、頁面模型和集成模型等，，，就完整了一個業務流、、、信息流和數據流三流合一的領域模型！所以，，，領域模型其實就是真實反應業務應用的物理模型。

本文試圖第一次詳細準確的描述對象、、、組件和模型之間的定義和關系。這三者是整個低代碼OKPAY錢包平臺最為核心的概念之一。

對于正在考慮重構的業務系統而言，，，對于既有IT資產中最為核心的業務模型和數據模型的繼承就是采取上述的梳理方法，，，然后通過低代碼做好對象建模的整體設計工作，，，這樣的重構才是嚴謹規范的，，，是成功交付的保障。

對于新建業務系統而言，，，上述過程其實就是新一代敏捷開發的全部基礎。敏捷開發絕不僅僅是簡單的迭代，，，我們認為敏捷開發是在完成領域模型后的搭建過程，，，而其核心基礎對業務的解耦和組件化的工程。

上一篇：官宣！OKPAY錢包數字官網煥新上線~

下一篇：力出一孔，，，向工而生｜OKPAY錢包&畢普科技戰略合并發布會圓滿收官

日本在线视频网站-日本在线视频网址-日本在线视频一区-日本在线视频在线-日本在线在线播放-日本在线中文字幕-日本中文高清欧美-日本中文视频在线-日本中文无码字幕-日本中文在线观看

OKPAY官網-高效安全私密的資產管理平臺

基于低代碼PaaS對于對象、、、模型及組建關系的全新解析

推薦新聞

Get Started，，，和OKPAY錢包一起構建無限可能

400-8128-288

關注我們

感謝您對OKPAY錢包的關注

日本在线视频网站-日本在线视频网址-日本在线视频一区-日本在线视频在线-日本在线在线播放-日本在线中文字幕-日本中文高清欧美-日本中文视频在线-日本中文无码字幕-日本中文在线观看

OKPAY官網-高效安全私密的資產管理平臺

基于低代碼PaaS對于對象、、、模型及組建關系的全新解析

推薦新聞

Get Started，，，和OKPAY錢包一起構建無限可能

400-8128-288

關注我們

感謝您對OKPAY錢包的關注

基于低代碼PaaS對于對象、、、模型及組建關系的全新解析

Get Started，，，和OKPAY錢包一起構建無限可能