基于(yú)低代碼PaaS對于(yú)對象、模型及組建關系的(de)全新解析
2022-09-27
低代碼技術與組件化趨勢之(zhī)間有着天然的(de)基因級的(de)融合優勢，這(zhè)種融合來(lái)自于(yú)共同的(de)解耦到(dào)封裝的(de)構建思路。但是(shì)，如何嚴謹規範地(dì / de)做好業務解耦，如何全面實現組件和(hé / huò)業務之(zhī)間的(de)準确匹配，如何對于(yú)對象的(de)定義和(hé / huò)層級進行劃分，對象、模型、組件三者之(zhī)間的(de)關系如何界定，目前業界缺乏統一(yī / yì ／yí)完整科學規範的(de)方法論。本文就(jiù)試圖對上(shàng)述問題予以(yǐ)探讨。
可組合的(de)業務(Business Composability)已經被Gartner倡導認爲(wéi / wèi)是(shì)應對業務創新中不(bù)确定性的(de)最佳策略和(hé / huò)方法，其核心思想是(shì)将具備業務共性的(de)業務元素沉澱形成組件化模塊化，以(yǐ)便快速地(dì / de)搭建新的(de)應用。Gartner爲(wéi / wèi)我們揭示了(le／liǎo)業務中、後台的(de)拆分要(yào / yāo)遵循的(de)三條核心原則：一(yī / yì ／yí)是(shì)可複用，二是(shì)跨系統的(de)共享，三是(shì)聚焦業務邏輯而(ér)非業務執行。
業務流程的(de)抽象和(hé / huò)業務功能的(de)拆分爲(wéi / wèi)針對領域模型爲(wéi / wèi)核心的(de)驅動設計以(yǐ)及服務化(微服務)在(zài)平台功能抽象拆分提供了(le／liǎo)相對值得借鑒的(de)思路，催化了(le／liǎo)以(yǐ)業務功能細分作爲(wéi / wèi)域劃分的(de)依據的(de)組件化方案，主要(yào / yāo)訴求是(shì)在(zài)細分的(de)業務功能組件服務基礎上(shàng)，能按需快速靈活地(dì / de)組合，從而(ér)支撐不(bù)同的(de)業務模式，提供業務敏捷性，支撐業務創新求變。
而(ér)且，這(zhè)種靈活組合的(de)另外一(yī / yì ／yí)個(gè)容易被忽略的(de)潛在(zài)價值在(zài)于(yú)試錯成本的(de)最小化。業務創新并不(bù)一(yī / yì ／yí)定總是(shì)成功的(de)，如果拆除一(yī / yì ／yí)個(gè)失敗的(de)創新業務，組件化的(de)架構也(yě)不(bù)會影響其他(tā)正常業務，其業務價值就(jiù)是(shì)極大(dà)的(de)打開了(le／liǎo)業務創新的(de)施展空間而(ér)無需擔心高昂的(de)試錯成本，這(zhè)就(jiù)使得通過新一(yī / yì ／yí)代組件化架構對類似ERP、PLM等大(dà)型傳統應用予以(yǐ)重構帶來(lái)可能。
看起來(lái)前景無限光明的(de)業務組件化，其前提條件毫無疑問是(shì)組件對業務的(de)支撐能力，而(ér)這(zhè)種能力，就(jiù)來(lái)自于(yú)對業務科學規範的(de)解耦和(hé / huò)映射的(de)方法。
業務元素應該包括業務對象、業務要(yào / yāo)素、業務邏輯和(hé / huò)業務規則等，将業務元素封裝在(zài)組件中的(de)核心技術就(jiù)是(shì)對象建模。應該說(shuō)，對象建模本身并不(bù)是(shì)高不(bù)可攀的(de)技術，通過各維度的(de)數據從邏輯和(hé / huò)屬性上(shàng)對業務實體做出(chū)科學準确的(de)表達是(shì)可以(yǐ)實現的(de)。這(zhè)其中最大(dà)的(de)挑戰在(zài)于(yú)對于(yú)對象的(de)定義和(hé / huò)分級，由此梳理清晰對象的(de)邊界和(hé / huò)組件之(zhī)間的(de)協作模式，爲(wéi / wèi)後續的(de)敏捷開發奠定基礎。顯然，混亂的(de)業務組件必然會對整體應用搭建造成隐患，如果對象定義不(bù)夠清晰，模型和(hé / huò)組件層級沒有準确匹配業務域和(hé / huò)業務能力的(de)支撐，對應用開發将是(shì)災難性的(de)。
所以(yǐ)，對象建模方法論就(jiù)顯得尤爲(wéi / wèi)重要(yào / yāo)。
真正的(de)難度在(zài)于(yú)如何準确地(dì / de)區分并定義不(bù)同層級的(de)對象、組件形成完整的(de)與業務的(de)對應關系，這(zhè)當然需要(yào / yāo)科學方法論的(de)指導。這(zhè)個(gè)方面，傳統企業EA架構理論中從業務模型到(dào)數據模型的(de)嚴謹規範的(de)設計思想以(yǐ)及數據治理思想中概念數據模型等理論值得借鑒。以(yǐ)下舉例說(shuō)明。
在(zài)軌道(dào)運維業務中，我們形成了(le／liǎo)完整的(de)從業務能力（業務域）-業務流程-業務實體-數據模型的(de)分析梳理過程。軌道(dào)運維業務能力如下圖所示：
匹配業務能力要(yào / yāo)求的(de)業務流程如下圖所示：
在(zài)上(shàng)述業務流程涉及到(dào)的(de)業務實體如下圖：
最後對應到(dào)真實發生的(de)數據實體上(shàng)，如下圖：
梳理完所有的(de)業務流程、業務實體、數據實體後可以(yǐ)将對象作出(chū)根據不(bù)同業務域的(de)清晰的(de)層級劃分，如下圖：
最終形成完整統一(yī / yì ／yí)的(de)軌道(dào)運維概念數據模型，如下圖：
可以(yǐ)看出(chū)，這(zhè)是(shì)一(yī / yì ／yí)個(gè)完整的(de)從具體到(dào)抽象的(de)高度提煉概括的(de)過程，整個(gè)過程緊密貼合實際業務，全面客觀地(dì / de)對應業務實體和(hé / huò)業務對象，最終實現數據對業務的(de)準确映射。
上(shàng)述這(zhè)個(gè)過程也(yě)是(shì)我們對象定義和(hé / huò)建模、組件定義和(hé / huò)分級、模型定義和(hé / huò)分級的(de)核心依據！
例如我們對“鋼軌”這(zhè)個(gè)實體對象做建模，通過9個(gè)邏輯維度、63個(gè)邏輯要(yào / yāo)素做好元數據定義和(hé / huò)約束，并形成關于(yú)“鋼軌”這(zhè)個(gè)對象組件，由此來(lái)支撐所有需要(yào / yāo)“鋼軌”這(zhè)個(gè)組件的(de)領域模型建設。
而(ér)“鋼軌”、“焊縫”、“扣件”、“軌枕”、“道(dào)床”、“道(dào)岔”、“伸縮調節器”、“接觸軌”、“軌道(dào)附屬設施”等所有的(de)對象完成建模和(hé / huò)組件化後就(jiù)可以(yǐ)完成“基礎設備信息”這(zhè)一(yī / yì ／yí)業務域的(de)局部領域模型建設，這(zhè)個(gè)模型對應的(de)就(jiù)是(shì)數據模型中的(de)一(yī / yì ／yí)級主題域，也(yě)可以(yǐ)對應業務模型中的(de)一(yī / yì ／yí)級業務域。而(ér)所有的(de)局部領域模型建設完成，就(jiù)可以(yǐ)實現針對全業務的(de)領域模型。
對象、組件和(hé / huò)模型其實都是(shì)有層級的(de)，是(shì)必須嚴謹對應到(dào)業務上(shàng)的(de)，也(yě)隻有這(zhè)樣的(de)嚴謹，才能将業務中那些最難發現的(de)、隐藏在(zài)實際業務中的(de)業務邏輯和(hé / huò)業務規則完整繼承下來(lái)。并且，這(zhè)種分析和(hé / huò)梳理的(de)過程，也(yě)是(shì)對IT核心資産的(de)完整繼承。IT的(de)核心資産，其實應該是(shì)現有系統中已經在(zài)運行、并證明對業務有真實支撐能力的(de)業務模型和(hé / huò)數據模型，而(ér)上(shàng)述解耦和(hé / huò)封裝的(de)過程，是(shì)完全基于(yú)對業務模型和(hé / huò)數據模型科學嚴謹的(de)學習和(hé / huò)理解的(de)過程。
以(yǐ)上(shàng)是(shì)方法論思想的(de)論述，更爲(wéi / wèi)技術角度的(de)解讀是(shì)從平台業務系統的(de)邏輯模型到(dào)物理模型的(de)直接映射爲(wéi / wèi)造成問題的(de)主要(yào / yāo)因素來(lái)出(chū)發的(de)。既然物理模型的(de)變更是(shì)平台不(bù)穩定的(de)動因，那麽我們是(shì)否能通過解耦業務邏輯模型和(hé / huò)物理模型的(de)映射關系來(lái)嘗試解決這(zhè)個(gè)問題呢？
基于(yú)上(shàng)述的(de)事例，我們需要(yào / yāo)對業務進行建模，對業務進行抽象，定義出(chū)業務邏輯模型，然後對模型進行二次抽象，定義出(chū)邏輯模型的(de)定義數據，實現業務模型的(de)數據化，即模型的(de)元數據(The Metadata of the Logic Model)，将模型結構存儲爲(wéi / wèi)數據，而(ér)不(bù)是(shì)直接對應的(de)物理存儲結構。其次根據定義出(chū)的(de)元數據進行統一(yī / yì ／yí)抽象，形成元數據邏輯模型。将元數據邏輯模型映射到(dào)元數據物理模型，對應實際存儲結構。
通過對業務模型的(de)變更形成對元數據層的(de)數據變更，而(ér)不(bù)是(shì)物理結構的(de)變更，從而(ér)實現業務邏輯模型同物理模型的(de)解耦。當然反過來(lái)，由于(yú)縱向功能細分，業務功能域增多，整個(gè)業務鏈條上(shàng)的(de)咬合點越來(lái)越多，
于(yú)是(shì)，可以(yǐ)得出(chū)的(de)結論是(shì)，最小業務組件顆粒其實就(jiù)是(shì)描述最小業務實體所對應的(de)業務對象，而(ér)組件要(yào / yāo)素就(jiù)是(shì)描述最小業務對象所對應的(de)元數據！而(ér)将該元數據所對應的(de)所有業務邏輯要(yào / yāo)素（屬性和(hé / huò)規則等）同業務對象一(yī / yì ／yí)起做好封裝就(jiù)形成了(le／liǎo)最小業務單元組件！
這(zhè)其實就(jiù)是(shì)傳統的(de)業務邏輯模型的(de)實現過程的(de)組件化。将某一(yī / yì ／yí)業務域所有業務組件做有機整合，結合流程模型、報表模型、頁面模型和(hé / huò)集成模型等，就(jiù)完整了(le／liǎo)一(yī / yì ／yí)個(gè)業務流、信息流和(hé / huò)數據流三流合一(yī / yì ／yí)的(de)領域模型！所以(yǐ)，領域模型其實就(jiù)是(shì)真實反應業務應用的(de)物理模型。
本文試圖第一(yī / yì ／yí)次詳細準确的(de)描述對象、組件和(hé / huò)模型之(zhī)間的(de)定義和(hé / huò)關系。這(zhè)三者是(shì)整個(gè)低代碼PaaS平台最爲(wéi / wèi)核心的(de)概念之(zhī)一(yī / yì ／yí)。
對于(yú)正在(zài)考慮重構的(de)業務系統而(ér)言，對于(yú)既有IT資産中最爲(wéi / wèi)核心的(de)業務模型和(hé / huò)數據模型的(de)繼承就(jiù)是(shì)采取上(shàng)述的(de)梳理方法，然後通過低代碼做好對象建模的(de)整體設計工作，這(zhè)樣的(de)重構才是(shì)嚴謹規範的(de)，是(shì)成功交付的(de)保障。
對于(yú)新建業務系統而(ér)言，上(shàng)述過程其實就(jiù)是(shì)新一(yī / yì ／yí)代敏捷開發的(de)全部基礎。敏捷開發絕不(bù)僅僅是(shì)簡單的(de)叠代，我們認爲(wéi / wèi)敏捷開發是(shì)在(zài)完成領域模型後的(de)搭建過程，而(ér)其核心基礎對業務的(de)解耦和(hé / huò)組件化的(de)工程。
滬公網安備 31011802004687号
