領域驅動設計在國有企業經營管理信息系統建設中的實踐

黃崟釗

一、背景

1.領域驅動設計概述

領域驅動設計（Domain-Driven Design，DDD）由著名建模專家Eric Evans 于2003年提出，是一個針對大型復雜業務系統的領域建模方法體系。近幾年，多個大型互聯網企業均已在相關產品線上開展了相關實踐并取得了不錯的成效，也讓這個只在國外流行的方法論逐漸被國內所熟知。

領域驅動設計改變了傳統軟件開發工程師針對數據庫建模的方式，通過面向領域的思維方式，將要解決的業務概念和業務規則等內容提煉為領域知識，然后借由不同的建模范式將這些領域知識抽象為能夠反映真實世界的領域模型。

2.國有企業的創新性被激發

一直以來，國有企業的“金字塔”型管理架構深受詬病。權利不斷向上集中、決策周期長、員工放不開手腳，導致國有企業普遍保守、缺乏創新性，繼而在市場上缺乏競爭力。

然而，近幾年國家大力推進的國企混合所有制改革以及國有企業數字化轉型，為國有企業注入了新的活力。一方面，國有資本和民間資本融合，雙方優勢互補。另一方面，互聯網、大數據、云計算、人工智能、區塊鏈等技術加速創新，大大加快了國有企業數字化轉型的進程。

在此背景下，國有企業的創新性紛紛被激發，部分國有企業領導層也更愿意接受新鮮事物。為本文中提到的某國有企業通過領域驅動設計方法論來自建經營管理系統奠定了基礎。

二、解決方式

1.搭建項目團隊

采取“領導牽頭、技術主導、全員參與”的方式搭建項目團隊。

首先，由公司領導牽頭，成立領導小組。領導小組由公司核心領導和聯合工作組組成。公司核心領導在項目組織建立、重大業務需求決策、關鍵方案審議、資源保障等方面有絕對話語權。聯合工作組由各部門中高層組成，負責日常事務過程中一般業務需求的決策。

其次，由研發部門選聘項目經理，協調各方開展領域驅動設計實踐以及企業經營管理系統的搭建。

最后，由聯合工作組確認實施小組人員名單。實施小組分為業務組和技術組。各部門應該至少安排一名業務代表，作為業務組成員，全程參與到項目建設過程中，業務代表也就是領域驅動設計方法論中的“領域專家”。技術組根據不同的專業分工，分設需求組、設計組、開發組、測試組、實施組等，組長即項目經理。

2.著手戰略設計

項目團隊搭建完成，即可開始戰略設計。戰略設計是為了降低系統復雜度，分而治之。直接面對企業經營管理這樣的大業務我們可能無從下手，必須將企業經營這個大的業務拆成市場、項目、合同、開票、回款、采購、人力資源、綜合事務等相對較小的業務，然后繼續拆解，直至我們完全可以在一個業務范圍內開展討論與建模。“劃分領域，分而治之”，是領域驅動設計的核心思想。

領域指的是范圍與邊界。將業務細分到一定程度后就能形成邊界，在邊界之內我們能建立起解決對應業務問題的領域模型。將領域進一步細分，我們就能得出“子域”。子域就是在領域內更細的業務邊界與范圍。

核心域、通用域和支撐域都屬于子域，但他們的重要性與功能屬性不同。包含企業核心業務和競爭力的子域可以劃為核心域；可以同時被多個子域調用、具有通用功能的子域可以劃為通用域，例如組織、員工等。除核心域和通用域之外的子域可以算是支撐域，如數據字典、消息通知等。

如何區分核心域、通用域與支撐域沒有統一標準，根據企業自身特征劃分即可。某國有企業經營業績壓力大，需要在營銷、財務等方面發力，所以將市場、項目、財務等領域劃為核心域，將人資、綜合、采購等領域劃為通用域。

3.開展事件風暴

戰略設計完成后，需要編制事件風暴計劃，按照“核心域-通用域-支撐域”的順序，依次開展事件風暴。

事件風暴（Event Storming）類似頭腦風暴，開發者與領域專家在一個足夠大的白板上，使用藍色的便簽紙羅列出領域中所有的領域事件，然后使用黃色的便簽紙標注出導致該事件的命令，再用綠色的便簽紙為每一個事件標注出命令發起方的角色。顏色的使用可以根據使用者的習慣調整，只需要確保事件、命令、角色使用的顏色不同即可。最后對事件進行分類，整理出實體、聚合、聚合根以及限界上下文。

在開展事件風暴時，需確保本次事件風暴討論的子域的相關部門均有領域專家到場。例如，在討論“銷售合同”時，可能涉及銷售合同的簽訂、開票、回款、閉合等業務，那么這次事件風暴就需要業務人員、合同歸口部門、財務人員至少3 名領域專家在場，以保證各方對本次事件風暴的結果達成共識。另外，實踐證明，除了開發者和領域專家，系統未來的測試人員、實施人員和運維人員也需要參與事件風暴，以便于讓所有人對業務的認知在同一水平線上。

4.建立統一語言

統一語言是整個項目團隊在溝通交流時使用的語言。統一語言應該“確保統一，隨時記錄”。

“確保統一”就是說，無論你在項目團隊中扮演什么樣的角色，你使用的語言就必須是統一語言。很多時候，即使是“老同志”或者“部門骨干”，也會在業務流程和概念上產生分歧。當各個部門領域專家與開發者共同創建領域模型的時候，往往會引起激烈的討論，每個人都會與其他人達成一致或者妥協，但最終都是為了創造最適合項目團隊的統一語言。以該國有企業為例，在一次事件風暴過程中，業務人員、營銷人員和財務人員對“項目”的定義不一致，為保證語言的統一，演化出了“銷售項目”“采購項目”和“非收支類項目”等概念，并對這些概念進行了嚴格的釋義，三方對新演化出的概念達成了一致，后續交流時大家都采用新的統一語言進行交流。

“隨時記錄”是指，統一語言的產生是隨時可能發生的。統一語言既來源于國家標準、行業標準、公司制度，也來源于需求調研、事件風暴、日常交流。開發者需要安排專人隨時記錄統一語言，避免遺忘。隨著時間的推移，統一語言將會不斷壯大成長，成為團隊的知識庫。

5.完成領域建模

領域驅動設計通過領域模型同時滿足分析建模、設計建模和實現建模的需要，從而將分析、設計和編碼實現糅合在一個整體階段中，避免彼此的分離造成知識傳遞帶來的知識流失和偏差。領域模型的邊界稱為限界上下文（bounded context）。一個限界上下文內，所有的概念必須是清晰的，即統一語言。

開發團隊在針對領域邏輯進行分析、設計和編碼實現時，都在進行領域建模，產生的輸出無論是文檔、設計圖還是代碼，都是組成領域模型的一部分。

6.持續迭代優化

系統采用前后的分離架構。前端使用Vue 和ElementUI 作為開發框架，進行組件化、模塊化開發；后端使用JAVA 語言，框架采用Springboo+Mybatis+Myb atisplus+RabbitMq；移動端使用uni-app 框架，組件采用uView，uni-app 可以將一套代碼同時編譯打包成安卓和蘋果的apk/app；同時代碼管理使用Git，版本依賴使用Maven 進行管理。

開發模式采用迭代開發模式。迭代式開發適合那些需求信息不明確的項目，每次只設計和實現這個產品的一部分。相對于傳統的瀑布流式開發，每次設計和實現的一個階段叫做一個迭代，每一次迭代都包括了需求分析、產品設計、開發與測試，因此每一個迭代都是一個完整的瀑布模型。在實踐中，建議核心模塊搭建時期、系統上線之前的迭代可根據團隊默契程度定為2～4 周，系統上線后的試運行期可縮短迭代周期至1～2 周。

三、預計成效

國有企業通過領域驅動設計作為方法論，自建企業經營管理系統，預計可取得以下成效。

1.為各部門提供經營活動管理工具、日常事務處理工具，提高工作效率并通過信息系統建設，規范經營管理過程，建立經營管理過程中各環節之間數據的有效連接，實現公司經營活動的精細化管理，提升管理水平。

2.通過對數據的挖掘和分析，實現數據驅動型管理，為企業管理者提供科學的統計報表以及有效的數據可視化界面。并為企業管理者建立數據使用后評價機制，科學評估各個決策帶來的影響，降低決策風險。

3.借助事件風暴、統一語言等工具，將開發人員、設計人員、領域專家對業務的認知拉到同一水平線，降低需求分析與系統設計的風險，避免系統的反復修改。通過前期的充分準備將系統建設風險前置，達到“先慢后快”的效果，提升系統開發效率。

四、經驗總結

1.管理層重視是關鍵

企業經營管理系統是企業的主要生產經營協作工具，系統的建設是“一把手工程”。在重大事項決策以及各類事務優先級等方面，公司核心領導必須給予明確答復。另外，國有企業轉型時，業務部門有很大的業績壓力，希望有更多的自由度去開拓市場，而國有企業的職能部門則經常面臨網絡攻防演練、上級單位巡查、審計檢查等事務，更注重網絡安全、合規管理以及風險控制。兩者的特性決定了他們之間的矛盾是不可避免的、常態化的。在雙方對業務認知沖突、爭執不下時，就需要公司核心領導牽頭，在二者之間尋找平衡。

2.全員參與是基礎

企業的經營管理是一個多方協作的過程，系統建設過程中的需求收集、分析、評審等需要各部門全程參與，以便保障業務需求和系統需求的一致。領域專家和技術人員在一起工作，能保證開發出來的軟件是能夠準確傳遞業務規則的。無論是實踐領域驅動設計，還是做好企業經營管理系統的搭建，每個部門均需要有至少1 名管理者和1～2名領域專家全程參與系統建設，不得缺失。

3.業務上的共識是核心

信息系統只是工具，在實踐領域驅動設計時，更重要的是各方在業務上的共識。各部門的立場站位各不相同，推動工作要先拿共融，企業經營管理系統的搭建尤其如此。領域驅動設計的核心就是“業務驅動，而非技術驅動；業務建模，而非技術建模”，技術人員在與領域專家協作時應有意識地主導各方就每項業務達成共識。首先，各方應該就業務目標、意義、預期結果充分討論，明確需求目的；其次，求同存異，對于達成共識的概念及時記錄統一語言，對于暫時無法達成共識的地方重復以上步驟或者邀請管理層介入，逐步與各方達成共識。