天天看點

jxTMS-業務資料模型

jxTMS:低成本快速定制的業務開發平台。

jxTMS-業務資料模型

在前幾天關于一個無代碼的回答【無代碼程式設計會是以後的趨勢嗎?】中,筆者大緻講了下不同的研發思路。

就本質來說,拖拽自搭建的方案其實是以資料為核心的呈現技術,是基于一個完備的業務處理系統,讓業務人員根據自己的業務需求就地找資料、取資料、看資料、用資料。即系統處理好資料,讓業務人員自助使用。

了解了這一點,想到jxTMS的實作中是以業務邏輯為中心,是以資料的操作與呈現是一體的,确實需要為自助使用做下準備,是以在借鑒了華為數字底座的治理方法論後,依托既有設施實作了jxTMS的業務資料解決方案。

業務資料

經過思考,筆者形成了業務資料的概念:

業務資料是經過加工的資料,具有一系列業務屬性與業務計算的業務資訊集合,用來訓示業務的運作,可以被其它業務環節直接利用與二次處理

比如,運輸方式。在拟定合同時,選擇了哪種運輸方式,就包括了相應的包裝方式、運費、保險費、在途時間、傳遞地與傳遞方式等一系列的業務處理結果,這些業務處理都是規範化的,具有預測算能力。是以,使用者通過給出貨物清單就能自動計算運費、預估時間、外包裝尺寸等,即可實作業務自動化、服務自助化。

也就是說,業務資料是規範化的、自帶業務計算标準接口的源資料。這裡的源資料是指離開資料的生成地之後,隻能被引用,但不能被修改,即誰管理誰維護,他人隻能按權限引用,而不得修改。

是以,業務資料具有如下的要求:

  • 誰管理誰維護,引用方不得修改,不得轉發
  • 基于角色的授權
  • 通過中繼資料進行描述
  • 資料名額化,即通過這些資料可測量、審計、評價具體的業務過程。目前可暫時放一放
  • 資料預校驗,即關聯準入檢測,在資料進入時進行校驗,進而提高資料品質
  • 内置業務規則,可随時對業務進行合規性檢測,從源頭保障業務的合規性
  • 可計算,可随時根據實際情況進行業務測算,提高業務的戰術決策水準

有了業務資料的概念,則可整合之前已經開發好的各種既有設施,從之前的側重業務實作邏輯,變為封裝業務細節為标準化業務部件,以資料流為抓手來梳理、整合業務過程,簡化業務開發。

業務資料的外部通路

外部對業務資料的使用,一共有五種:

  • 流:流式樣的資料其實就是資料序列,類似一個根據約定用引用者所給參數執行的查詢,隻不過在查詢出相關原始資料後,在逐行向引用者饋送前先由業務子產品加以處理,再将處理後的資料送出給引用者

注:如果原始資料不符合業務要求,業務子產品可能會将其過濾掉并不饋送給引用者。如量化交易需計算各交易政策的績效,績效的計算是以每天早八點的倉位為基準進行計算的,但一般來說,每天都會有多次交易,是以從交易流水中提取績效資料時就會出現業務子產品過濾掉交易資料的情況

  • 單體:單體資料同樣是一個根據約定用引用者所給參數執行的查詢,同樣在查詢出相關資料後,先由業務子產品加以處理,将處理後的資料送出給引用者。是以單體資料和流資料的差別就是一個和n個的差別
  • 計算:根據約定用引用者所給參數調用标準接口來執行相關的函數并傳回結果

注:計算應和業務處理的請求區分開,業務資料的計算結果隻是基于現有資料的測算,不會對現有資料有任何修改與影響

  • 合規性檢測:對引用者按約定送出的參數調用标準接口以實作用相應的規則表對這些參數進行業務合規性的校驗,如長寬高是否符合運輸條件、所要求的傳遞量超過庫存需要生産但客戶要求的傳遞期卻太短等等
  • 訂購:根據約定,引用者可以訂閱自己感興趣的資料或事件,當這些資料或事件産生後,負責業務資料的子產品将通知訂購者

流資料與單體資料,如果是類似華為的基礎資料與主資料這些基本不會變動或變動很少的資料,則可以啟用緩存特性。

注:基礎資料、主資料、事務資料等這樣的分類,jxTMS的業務資料模型作為基本模型不做區分

誰管理誰維護

這一原則的落地很簡單,上一小節也指出了業務資料隻有上述的五中讀取類型的接口。

作為開發約定,業務資料所對應的真實資料隻能在業務資料所在的功能子產品中處理,包括錄入、修改、整理等維護動作的實作。

授權

業務資料對象在擷取時需要根據引用者的角色執行授權檢查。如果授權不通過則傳回空的業務資料對象,而成功擷取即可以通過上述的四種方式使用而不再進行權限檢查。

由于jxTMS允許一個成員有多種角色,是以隻要這些角色中有一個通過授權即可。

授權是一個基于文本的、開發者可自定義的、由條件判斷組合起來的公式。如代碼的授權公式:

role.profession match '技術.研發.軟體' and role.level >= 20
           

意即:崗位字首為技術部門的研發類軟體崗,且職級應大于等于20。這樣,一個進階程式員就可以檢視代碼,但其上司,如果崗位字首是【技術.研發.管理】,那是無法檢視的;而崗位字首是【技術.研發】的上司就可以檢視。

注1:示例中的崗位字首和職級都是由該組織自行設定

注2:越短的崗位字首代表的是負責的領域越廣,自然權限就應越大

預校驗

預校驗可參考資料限制。隻不過是限制的位置從該文所指出的前後端移到了業務資料錄入時的前端【設在此處也意味着在多系統的自動勾連、自動采集時也可以起到作用,而不僅僅是人工錄入時的web前端】。

業務規則檢查

業務規則檢查可參考合規性保證,具體的實作技術可以參考業務規則。

業務計算

業務資料提供了相關的标準接口與映射架構,可以将引用者對某業務資料的約定通路自動映射為對相應capa中的某個函數的調用。

訂購

業務資料隻提供了關于訂購的标準接口架構來銜接訂購的消費者與生産者,具體的生産與消費,業務資料模型并不幹涉。為了進一步簡化業務資料模型的實作,目前當機後業務資料模型本身并不會重新恢複這些訂購,而是由生産者與消費者自行考慮當機後訂購的維持。

注:訂購的維持可放在initAtLoad修飾的函數中執行,以確定當機後的恢複

總結

業務資料模型通過封裝業務細節為标準化的業務部件,以資料需求來組裝業務,進一步簡化了業務開發。由于業務資料模型的實作,jxTMS也具備了自助組裝的基本能力。

筆者在10多年前就已經實作過web控件的拖拽搭建,但這種方式對非專業開發人員比較友好,可對于專業開發人員來說效率太低,由于jxTMS面向的就是專業開發人員,是以拖拽組裝就暫不考慮了。

繼續閱讀