模型驅動方法論在業務中臺中的實踐研究(一)

李忠民 何鑫

摘? 要：在某大型央企的業務中臺的建設過程中對模型驅動架構方法論進行了系統深入的研究，結合工作實踐提出了一個可行的模型序列，并總結出了一套模型轉換規則，之后進一步采用該方法論指導了中臺項目從分析、設計到落地的整個生命周期，實現了模型驅動架構在業務中臺項目的應用。文章對實踐經驗進行總結，重點就模型驅動架構的主要內容——模型序列及其轉換規則展開討論。

關鍵詞：模型驅動架構;業務過程建模;用例模型;組件模型;模型轉換

中圖分類號：TP311.52? ? ? ?文獻標識碼：A 文章編號：2096-4706（2020）17-0129-03

Abstract：In the process of the construction of a large central enterprises financial middle office，this paper makes a systematic and in-depth study on the MDA methodology，puts forward a feasible model sequence and summarizes a set of model conversion rules，and further adopts the methodology to guide the analysis，design and implementation of the project，so as to realize the whole life cycle of the project and realize the fall of MDA in the financial center project. This paper summarizes the practical experience and focuses on the main content of MDA model sequence and its transformation rules.

Keywords：MDA（model driven architecture）;business process modeling;use case model;component model;model transformation

0? 引? 言

最近，北京中電普華信息技術有限公司承建了某大型央企業務中臺的建設任務，業務中臺作為某大型央企的企業級應用，支持該企業總部和全國范圍的分支機構的相關業務。該企業在此前已經長期進行業務信息化建設，存在著數十個分立的業務系統，就像大多數企業一樣，這些系統呈煙囪狀，已經對企業的數字化形成阻礙。在此情境下我公司實施了中臺戰略，業務中臺作為該戰略的一部分，其目標是采用新的架構，繼承已有信息化成果，抽取公司各領域的有復用價值的業務模塊集成到業務中臺中，為該企業各業務條線提供公共服務。業務中臺是該央企的關鍵應用，業務復雜、涉及范圍廣、架構先進，相關領域的實踐不多，可資借鑒的經驗不多，因此設計一套成熟的、系統化的方法論來指導業務中臺的建設至關重要。

模型驅動架構方法論對系統分析和設計領域進行了概括和抽象，把系統分析和設計過程抽象為一系列前后依賴的模型的建模過程，其核心思想是只要對該序列的模型依次建模，就可以從業務逐步逼近實現，最后達到實現。該方法論給出了一個完整的、系統化的、前后銜接一致的解決方案，其覆蓋了從需求分析、系統設計、到系統實現的全生命周期，實現了業務需求的結構化描述，利用嚴謹的建模語言描述了結構、數據和行為，為系統的分析設計提供了一條邏輯嚴謹、步驟明確、接近可推理演算的實現方法;它可以確保設計反映業務，針對業務展開設計，確保設計意圖貫徹到實現中去，從而讓客戶更有可能獲得他們真正需要的系統。

但模型驅動架構（MDA）方法論只是提出了一個抽象的

理論，距離落地實施還有一段距離：首先其并沒有給出具體的模型序列，其次亦沒有給出模型間的轉化規則。故模型驅動架構方法的落地仍需實踐者自己去探索，去找到模型序列，并給出模型間的轉換規則，補齊抽象的方法論與具象的實踐間的空白。盡管這樣，MDA的思想在某些局部已得以實現，若借助市場上現有的CASE工具，再輔以人工編寫的一些腳本，是具備落地實施的可行性的。作為業務中臺的承建單位，公司認識到模型驅動架構的優勢，結合業務中臺的建設任務展開對MDA方法論的深入研究，并利用MDA指導業務中臺的建設實施。本文結合作者在業務中臺設計開發工作中的實踐，提出一個可行的模型序列，并在后續系列文章中給出模型轉換規則。

1? 模型驅動架構及其適用場景

在《應用MDA》一書中，作者提出“XP的核心部件是3GL代碼，而MDA的核心工件是模型”，這句話道出了MDA的本質，說明了MDA和時下流行的各種設計方法的區別，MDA更加重視設計，甚至試圖以設計代替開發。MDA適用于傳統的、注重設計的重型項目，但這并不意味著MDA在敏捷開發大行其道的時代就是過時的。實踐中我們往往在系統第一次建設時進行一個重型的設計過程，給系統搭建一個相對合理的架構，然后再利用敏捷方法不斷迭代升級、不斷完善，此時往往伴隨著架構的逐漸腐化，以致于到一定階段需要再用MDA來一次徹底的重構。而業務中臺是客戶企業中臺戰略的重要組成部分，是按照全新架構、全新思路建立的平臺，正適合采用MDA這種重型的設計方法論來指導。

2? 模型驅動架構方法的優點

在進行信息化系統開發時，我們面臨兩個突出的困難：一是如何確保設計反映業務，即如何確保我們是為了業務中臺進行設計，而不是拿出一個放之四海皆準的普適的方案;二是如何確保設計意圖貫徹到開發中去，即如何確保系統開發落實了設計方案。這兩個問題是多數項目中非常普遍且很難解決的問題，MDA可以很好地解決這兩個問題。

2.1? 確保設計反映業務

MDA通過把系統分析、設計、實現的過程抽象為一系列建模過程，把非結構化的過程工件結構化，借助工具實現模型對業務的全覆蓋，實現模型之間的信息交接無遺漏、不失真，且從分析到實現的全過程可追溯。

2.2? 確保實現貫徹設計

MDA借助工具提供輔助代碼生成功能，輸出包含業務邏輯和業務規則的代碼規約（即接口），這些規約規定了系統實現需要那些領域類、存在那些輔助類/接口規范，以及其業務邏輯和業務規則。開發團隊借助一些工具（如Swagger），可以自動根據這個規約生成前端和后端實現代碼。MDA也輸出物理模型建庫腳本，有些工具會基于建庫腳本生成DAO層甚至前端CURD代碼。

3? 可行的模型序列

在業務中臺實際工作中，本人提出一個MDA落地可行的模型序列，通過依次構建序列上的每個模型，描述模型中容納的概念，在模型序列的引導下，由業務逐漸逼近系統實現，該序列如圖1所示。

從業務空間到系統實現要經過四個視角的轉換，稱之為域，即業務域（業務流程模型、業務用例模型）、應用域（業務對象模型、領域模型）、數據域（概念模型、邏輯模型、物理模型）、技術域（組件模型）。每個域通過對一個或多個模型的建立，從不同視角描述同一個事物（即業務中臺的業務）。

3.1? 業務域

在業務域我們用直白的語言描述業務事實，不進行抽象。此階段使用的工具即業務過程模型，該模型又包括業務流程模型和業務用例模型。

該階段的核心工作是需求的結構化，即通過建立業務流程模型和業務用例模型，把從客戶那里收集到的非結構化的、碎片狀的需求信息結構化，用結構化數據描述業務空間，不但能確保分析人員全面描述業務，避免遺漏，而且將需求變成了數據。從需求到數據的這一轉換非常關鍵，此舉使得后續的系統分析和設計過程轉變為對數據的加工處理過程，可以利用數據處理的技術進行系統分析和設計，進一步豐富了我們進行系統分析和設計的手段，為確保實現“設計反映業務、實現貫徹設計”和做到“全覆蓋、無重復、無遺漏”的目標打下了基礎。事實上MDA強調模型間的自動轉換，需求的結構化是實現模型間自動轉換的基礎。

3.1.1? 業務過程模型建模

業務過程建模的基本方法是切分，首先由粗到細把業務中臺業務切分為業務產品、業務場景、業務單元（業務用例）、業務活動（系統用例）等不同粒度的模塊，其次定義這些模塊中包含的業務邏輯和業務規則，繼而描述這些模塊之間的關系。業務過程建模中有兩個關鍵問題要解決：一是如何確定模塊的粒度;二是如何實現業務需求的結構化描述，下文結合業務中臺的實踐嘗試進行分析。

3.1.2? 業務概念的粒度

業務模型中通過建立業務產品、業務場景、業務單元、業務活動、業務用例、系統用例等概念對業務中臺的業務進行不同粒度的逐級切分，分而治之，為建立業務中臺業務的結構化描述提供概念框架。既然談起劃分，就面臨粒度的問題，筆者的認識是，粒度的把握取決于概念的用途，業務產品、業務場景等高層概念的劃分粒度和維度必須是客戶能夠理解的，與客戶的認知保持一致。最細粒度的概念的粒度把握最為關鍵，必須是可結構化的，是能夠用于指導后續設計、有利于后續模型的建模復用的。在業務中臺項目中，我們約定業務過程模型中最細粒度的概念是業務活動，其粒度為一次包含業務邏輯處理過程的人機交互或者系統間的交互，同時為了簡化方法論的復雜度，約定系統用例等價于業務活動。

3.1.3? 需求的結構化

在業務過程模型的幾個業務概念中，最細一級的業務概念即業務活動最為關鍵，在業務中臺項目中，業務需求的結構化描述主要是在業務活動中展開，UML和BPMN2.0等建模語言都為需求的結構化提供了支持。如UML的行為元素提供了規范、輸入參數、返回值等項;約束元素通過Post-condition、Pre-condition、OCL等項目提供結構化手段;規則元素則通過結構性描述規范提供了對業務步驟的詳細描述手段。

由于項目的時間成本限制和團隊對UML的實際理解程度的原因，我們實踐中在需求的結構化方面采用通俗易懂的約束+規則兩種元素來結構化業務需求。

3.2? 應用域

該域從功能、服務角度描述業務，用業務的語言回答怎么做，在應用域有兩個模型：業務對象模型、領域模型。

3.2.1? 業務對象模型的建立及其重構過程

業務過程模型給出了完整的、詳細的業務需求的結構化描述，不過這種描述是面向過程的;業務對象模型則實現一個跳躍，從面向對象的視角給出業務描述，可以說業務對象模型幫助我們從面向過程的分析進入了面向對象的分析。在業務中臺項目中借助建模工具和自己編寫的自動化腳本（這也體現了上一階段需求結構化的好處），實現了面向過程描述向面向對象描述的部分自動轉換，同時確保業務過程模型向業務對象模型的轉換過程中信息全繼承、無遺漏。

3.2.1.1? 業務對象的識別

業務對象包含方法和屬性，其方法由業務過程模型的業務活動（或系統用例）遷移而來，其屬性由業務過程模型中的輸入輸出信息遷移而來。對轉過程可借助自動化工具自動完成。

業務對象識別的過程為：

（1）首先從業務過程模型的輸入輸出業務信息中抽象出業務對象，同時建立業務對象和輸入輸出業務信息的“血緣關系”。

（2）遍歷所有與該業務對象存在“血緣關系”的輸入輸出業務信息，取其數據項作為業務對象的屬性。

（3）遍歷所有與該業務對象存在“血緣關系”的輸入輸出業務信息，進一步管理與這些輸入輸出業務信息相關聯的業務活動或者系統用例，取這些業務活動或者系統用例作為該業務對象的方法。

3.2.1.2? 業務對象模型的重構

通過上述三步得出業務對象的原型，然后對業務對象模型進行重構：

（1）語義分析：1）對于重復的對象，做去重處理;2）對于有共同祖先的對象，建立抽象父類，與父類之間建立泛化關系;3）對于語義有交叉的業務對象，進行拆分，根據需要定義新的業務對象或者合并業務對象。

（2）對象間關系分析：1）識別對象的聚合、組合關系;2）識別對象的依賴關系。

（3）屬性和方法的語義分析：由于業務對象的屬性是由有“血緣關系”的業務信息的數據項的簡單合并，且在做去重處理時進一步合并了屬性和方法，因此必然存在屬性重復、方法重復的情況，所以需要繼續對同一個業務對象內的屬性、方法進行合并、去重處理，處理過程與第一步語義分析過程類似。

（4）對標處理：1）規范命名：業務對象的命名、方法的命名、輸入輸出參數的命名都要符合命名規范，不規范的命名要進行規范;2）分析業務實現和業務應用場景，調整不合理的定義，比如對于身份證號，要替換為證件種類和證件號碼兩個字段;3）與數據詞典對標：業務對象的屬性必須來自數據字典，即要與數據字典中的某個單詞建立映射關系，其語義、值域要保持完全一致。

3.2.2? 領域模型的建立及其重構過程

領域模型完全繼承業務對象模型的業務對象和對象間關系等信息，并在此基礎上做了以下兩方面的工作。

3.2.2.1? 由業務描述向功能定義轉變

分析領域對象從業務對象中繼承過來的行為，識別業務實現需要的功能支持，這些功能或者抽象為領域對象，或者作為領域服務存在。

3.2.2.2? 識別對象之間距離關系

建立聚合，并定義聚合根、領域服務。為了簡化設計，項目中約定以下內容：

（1）聚合：聚合是內聚性很高的領域對象的組合。聚合實現了對業務規則的封裝，約定聚合是由具有數據一致性要求、需要變動的一組實體組成，并約定微服務的最小邊界不能小于聚合（事實上一般要遠大于聚合），這樣的聚合能夠避免分布式事務。

（2）聚合根：聚合中主要的領域對象，代表聚合對外提供訪問接口，約定只有聚合根才提供有業務含義的對外接口方法，如簽訂合同、終止合同等，聚合中的其他實體只提供CRUD操作;在聚合之外要訪問聚合只能通過訪問聚合根的接口方法實現。

（3）領域對象：為了簡化設計，約定領域對象等價于業務對象。

（4）領域服務：無法歸于某個領域對象，是可復用、無狀態的獨立服務。

4? 結? 論

模型驅動架構方法論出了系統分析設計的全局性的、協調一致的全景視圖，實現了業務需求的結構化描述，在一定程度上實現了計算機輔助系統的分析和設計。某大型央企業務中臺建設的實踐證明該方法論是完全可以落地的，其能夠確保每一項設計都有依據、每一個結論都可追溯，能夠確保設計成果反映業務，確保設計成果貫徹落實，從而讓客戶更有可能獲得他們真正需要的系統，是一種非常有價值的系統分析和設計方法。

參考文獻：

[1] 張鵬，李忠民.企業級數據模型全域一致性的一種解決方案 [J].智庫時代，2018（35）：135-136+139.

[2] FRANKEL D S.應用MDA [M].鮑志云，譯.北京：人民郵電出版社，2003.

[3] KLEPPE A，WARMER J，BAST W.解析MDA [M].鮑志云，譯.北京：人民郵電出版社，2004.

作者簡介：李忠民（1967—），男，漢族，山東聊城人，技術專家，中級職稱，本科，研究方向：銀行應用系統設計開發、大型互聯網平臺架構設計、大數據應用系統設計;何鑫（1988—），男，漢族，內蒙古烏蘭察布人，助理工程師，本科，研究方向：國網公司統一數據模型（SG-CIM）設計。