DDD 實踐：如何用 DDD 重構中臺業務模型？
進入 21 世紀，互聯網應用迅猛發展，衆多傳統企業紛紛 “觸網”，搭建起自己的互聯網電商平臺。隨後，微信、App 等移動互聯應用強勢崛起，掀起了新一輪的移動應用熱潮。
這些移動互聯應用，大多面向個人用戶或第三方，市場需求瞬息萬變，這就要求它們必須以敏捷的速度適應市場的變化。爲了滿足快速響應與頻繁發版的需求，許多移動互聯網應用選擇獨立於傳統核心系統進行建設。然而，兩者承載的業務大多相似，這就極易導致業務能力出現重疊。
阿里巴巴曾引領傳統企業向互聯網電商轉型。如今，時代進入新的歷史時期，在阿里巴巴提出中臺戰略後，衆多企業緊隨其後，高舉中臺大旗，轟轟烈烈地踏上數字化轉型之路。那麼，傳統企業在中臺轉型過程中，如何從錯綜複雜的業務裏構建中臺業務模型呢？今天，我將通過一個傳統企業中臺建模的案例，帶你運用 DDD 的設計思想，一同構建中臺業務模型。
傳統企業應用分析
互聯網電商平臺和傳統核心應用，兩者面向的渠道和客戶不一樣，但銷售的產品卻很相似，它們之間的業務模型既有相同的地方，又有不同的地方。現在我拿保險行業的互聯網電商和傳統核心應用來做個對比分析。
我們看一下下面這張圖，這兩者在業務功能上會有很多相似和差異，這種相似和差異主要體現在四個方面。
-
核心能力的重複建設
以保險行業爲例，當傳統保險核心應用與互聯網電商平臺銷售同質保險產品時，二者在覈心業務流程和功能上呈現出相似性。傳統保險核心應用具備報價、投保、覈保和出單等功能，互聯網電商平臺同樣也有這些功能。這就導致在覈心業務能力上不可避免地出現功能重疊，造成資源浪費和管理成本增加。
2. 通用能力的重複建設
傳統核心應用的通用平臺通常規模龐大、功能齊全，但也較爲笨重。互聯網電商平臺雖然依賴這些通用能力，但爲了保持自身的敏捷性，往往會自行搭建縮小版的通用功能，例如用戶管理、客戶管理等。這種重複建設不僅耗費人力、物力，還使得企業內部系統架構變得更爲複雜。
3. 業務職能的分離建設
部分業務功能在互聯網電商平臺和傳統核心應用中分別建設，且二者功能互補，共同構成完整的業務職能。以繳費功能來說，互聯網電商平臺主要面向個人客戶，多采用支付寶和微信支付等便捷方式；而傳統核心應用主要在櫃檯操作，依舊使用移動 POS 機繳費。爲了確保業務模型的完整性，在構建中臺業務模型時，可考慮將這兩部分進行重組，形成一個完整的業務模型。
4. 前後端完全獨立建設
傳統核心應用主要服務於櫃檯業務，因此並不需要互聯網電商平臺所具備的在線客服、話務、訂單和購物車等功能；而互聯網電商平臺主要面向個人客戶，也無需後端較爲複雜的再保、佣金、打印等功能。在構建中臺業務模型時，針對這種情況，應當區別對待，將面向後端業務管理的應用沉澱到後臺，把前端能力構建成面向互聯網渠道的通用中臺，如訂單中臺等。這樣的處理方式能夠有效整合資源，提升企業的整體運營效率。
如何避免重複造輪子？
要有效避免企業內部的重複建設，關鍵在於深入理解中臺的理念和思想。我們常說 “中臺是企業級能力複用平臺”，這裏的 “複用” 通俗來講，就是重複使用，目的就是防止做重複造輪子這種浪費資源的事。
中臺的設計思想與 “高內聚、低耦合” 的設計原則高度契合。所謂高內聚，就是把相關的業務行爲集中整合在一起，不相關的行爲則安排到其他地方。這樣一來，要是需要修改某個業務行爲，只需在一處進行修改即可。沒錯，中臺就該遵循 “高內聚、松耦合” 的原則，實現企業級的能力複用。
那當企業遇到重複造輪子的情況時，該如何應對呢？這就需要站在企業整體的高度去考量，將那些重複的、需要共享的通用能力和核心能力沉澱到中臺。同時，把分散的業務能力重新組合，形成完整的業務板塊，以此構建可複用的中臺業務模型。具體來說，前端的個性化能力就歸前端負責，後端的管理能力則由後臺承擔。通過這種方式，建立起前、中、後臺邊界清晰，又能相互融合協作的企業級可複用業務模型，從而提升企業整體的運營效率和資源利用率，避免不必要的重複建設。
如何構建中臺業務模型？
我們可以用 DDD 領域建模的方法來構建中臺業務模型。你可以選擇兩種建模策略：自頂向下和自底向上的策略。具體採用哪種策略，你需要結合公司的具體情況來分析，下面我就來介紹一下這兩種策略。
- 自頂向下的策略
在企業數字化轉型進程中，有效規避重複建設是提升效率、節約資源的關鍵，而這離不開對中臺理念與思想的深度領會。中臺被定義爲 “企業級能力複用平臺”，“複用” 即重複使用，旨在杜絕重複造輪子這類資源浪費現象。
中臺設計思想與 “高內聚、低耦合” 原則緊密相連。高內聚是將關聯業務行爲整合一處，無關行爲放置別處，這使得業務行爲修改只需在一處操作，十分便捷。中臺正是遵循 “高內聚、松耦合” 原則，達成企業級能力複用。
當企業面臨重複造輪子問題時，需從企業整體視角出發，將重複且需共享的通用能力、核心能力沉澱到中臺，整合分散的業務能力，構建可複用的中臺業務模型。具體而言，前端負責個性化能力，後端承擔管理能力，構建前、中、後臺邊界明晰且協同合作的企業級可複用業務模型，提升運營效率，避免重複建設。
下面介紹第一種策略 —— 自頂向下。這種策略的核心是先開展頂層設計，從最高領域逐步細化分解至中臺，並分別構建領域模型。依據業務屬性，中臺又可分爲通用中臺和核心中臺。在領域建模階段，主要依據業務實際狀況進行，暫不考慮現有系統。自頂向下策略適用於全新應用系統開發，或是舊系統全面重構的情形。由於不受現有系統的制約，可採用 DDD 領域逐級分解的領域建模方法。主要步驟如下：
-
領域分解
：把領域拆分爲子域，子域包含核心域、通用域和支撐域。
2. 子域建模
：對各子域進行建模，明確領域邊界，構建領域模型和限界上下文。
3. 微服務設計
：依據限界上下文進行微服務設計。
- 自底向上的策略
在闡述完自頂向下的策略後，下面爲你介紹第二種策略 —— 自底向上。這種策略的特點是緊密依託業務和系統的當前實際狀況來開展領域建模工作。
其具體實施過程如下：首先，針對每個系統所處的業務域分別進行全面的領域建模。在這個過程中，深入剖析各個業務域的業務流程、規則以及數據關係等，從而構建出相對獨立的領域模型。接着，進行業務域對齊操作，即仔細甄別出那些具有相同或相似業務功能的領域模型。通過對比分析這些模型之間的差異，對領域對象進行重新組合，進而對領域模型進行重構。在這一過程中，能夠有效沉澱出公共的、可複用的業務能力，同時將原本分散的業務模型進行有機整合 ，形成更爲高效、統一的業務架構。
自底向上策略尤其適用於遺留系統業務模型的演進式重構。通過這種方式，能夠充分利用現有系統的資源，在不進行大規模推倒重建的基礎上，逐步優化和完善業務模型，降低系統改造的風險和成本。
接下來，我將以互聯網電商和傳統核心應用的幾個典型業務域爲實例，詳細爲你講解如何運用自底向上的策略來構建中臺業務模型，主要分爲以下三個步驟。
第一步：鎖定系統所在業務域，構建領域模型。
鎖定系統所在的業務域，採用事件風暴，找出領域對象，構建聚合，劃分限界上下文，建立領域模型。看一下下面這張圖，我們選取了傳統核心應用的用戶、客戶、傳統收付和承保四個業務域以及互聯網電商業務域，共計五個業務域來完成領域建模。
從上述示意圖中，我們能夠清晰地看到，傳統核心系統共構建了八個領域模型。在用戶域，搭建了用戶認證和權限這兩個領域模型；客戶域則構建了個人與團體兩個領域模型；傳統收付領域構建了 POS 刷卡領域模型；承保域構建了定報價、投保和保單管理三個領域模型。而互聯網電商構建了報價、投保、訂單、客戶、用戶認證和移動收付六個領域模型。
對比這些領域模型清單，不難發現，傳統核心系統與互聯網電商之間存在諸多名稱相似的領域模型。經過深入分析會發現，這些看似相似的領域模型，實則存在業務能力重複的情況，或者像移動支付與傳統支付這樣，業務職能處於分散狀態。
基於此，在構建中臺業務模型時，我們就需要重點聚焦這些領域模型。將不同領域模型中重複的業務能力，精準沉澱到中臺業務模型中，同時把分散的領域模型整合爲統一的中臺業務模型，最終對外提供統一且共享的中臺服務。如此一來，便能有效提升企業資源的利用效率，減少重複建設帶來的資源浪費，推動企業數字化轉型的順利進行。
第二步：對齊業務域，構建中臺業務模型。
從這張圖中，我們能直觀地發現，右側傳統核心的領域模型數量明顯多於左側互聯網電商的領域模型。由此，我們可以初步推斷：傳統核心主要面向企業內部的大部分應用，追求全面覆蓋，所以其領域模型相對完備；而互聯網電商僅面向單一渠道，領域模型相對單一。
這一結論爲我們構建中臺業務模型提供了方向。我們可以將傳統核心的領域模型作爲構建中臺業務模型的主要依據，把互聯網電商領域模型當作輔助。具體來說，先把互聯網電商中重複的能力整合到傳統核心的領域模型中，互聯網電商則僅保留像訂單這類個性化能力。
在中臺業務建模過程中，我們不僅要注重領域模型的完備性，以確保業務的全面支持；還要充分考慮不同渠道對市場的敏捷響應需求，使中臺既能承載豐富的業務功能，又能靈活應對市場變化，從而提升企業整體的競爭力和運營效率，有力推動企業數字化轉型進程。
基於已有的構建中臺業務模型思路，我們正式開啓構建之旅。首先，從互聯網電商和傳統核心的領域模型入手，歸納並分離出能夠覆蓋這兩個域的全部業務子域。經過深入分析，我們確定了用戶、客戶、承保、收付和訂單這五個業務域，它們將作爲領域模型對比分析的基準域。
接下來，我以客戶業務域爲例，詳細闡述客戶中臺業務模型的構建過程。互聯網電商的客戶主要面向個人客戶，除了具備個人客戶信息管理功能，出於營銷目的，還設有客戶積分功能。所以，其領域模型包含個人和積分兩個聚合。反觀傳統核心客戶，不僅支持個人客戶，還涵蓋單位和組織機構等團體客戶，擁有個人和團體兩個領域模型。在個人領域模型中，除個人客戶信息管理功能外，還涉及個人客戶的評級、重複客戶的歸併以及客戶的統一視圖等功能，對應個人、視圖、評級和歸併四個聚合。
構建多業務域中臺業務模型的關鍵在於，找出同一業務域內所有同類業務的領域模型，對域內領域模型和聚合的差異與共同點展開對比分析，突破原有的模型框架，完成新中臺業務模型的重組或歸併。我們將互聯網電商和傳統核心的領域模型進行分解後，發現了五個與個人客戶領域相關的聚合，分別是個人、積分、評級、歸併和視圖。這些聚合原本分散在不同的領域模型中，現在需要打破原有的領域模型限制，進行功能沉澱和聚合的重新組合，重新確定這些聚合的限界上下文，進而重構領域模型。最終，個人客戶的領域模型重構如下：將個人、歸併和視圖三個聚合重構成個人領域模型，主要負責客戶信息管理；評級和積分兩個聚合重構成評級積分領域模型，主要面向個人客戶。到這裏，個人客戶領域模型構建完成。
等等，似乎還有遺漏。沒錯，還有團體客戶領域模型！實際上，團體客戶相對簡單，因爲它僅在傳統核心中出現，我們直接將其在傳統核心中的領域模型拿來使用即可。至此，我們成功完成了客戶中臺業務模型的構建，該中臺包含個人、團體和評級積分三個領域模型。
通過這次客戶中臺業務模型的構建過程，你是否掌握了構建中臺業務模型的要點呢？簡單總結就是：“分域建模型，找準基準域，劃定上下文，聚合重歸類。” 其他業務域的構建過程亦是如此，這裏就不再逐一贅述。大家可以自行練習，將其作爲課後作業。完成後，可對照下面這張圖進行檢查，這是其他業務域重構後的中臺業務模型。
第三步：中臺歸類，根據領域模型設計微服務。
完成中臺業務建模後，我們就有了下面這張圖。從這張圖中我們可以看到總共構建了多少箇中臺，中臺下面有哪些領域模型，哪些中臺是通用中臺，哪些中臺是核心中臺，中臺的基本信息等等，都一目瞭然。你根據中臺下的領域模型就可以設計微服務了。
重構過程中的領域對象
上面主要是從聚合的角度來描述中臺業務模型的重組，是相對高階的業務模塊的重構。業務模型重構和聚合重組，往往會帶來領域對象和業務行爲的變化。下面我帶你瞭解一下，在領域模型重組過程中，發生在更底層的領域對象的活動。我們還是以客戶爲例來講述。由於對象過多，我只選取了部分領域對象和業務行爲。傳統核心客戶領域模型重構之前，包含個人、團體和評級三個聚合，每個聚合內部都有自己的聚合根、實體、方法和領域服務等。
互聯網電商客戶領域模型重構前包含個人和積分兩個聚合，每個聚合包含了自己的領域對象、方法和領域服務等。
將傳統核心和互聯網電商的客戶領域模型重構成客戶中臺後，形成了個人、團體和評級積分這三個領域模型。其中，個人領域模型包含個人聚合，團體領域模型包含團體聚合，評級積分領域模型則由評級和積分兩個聚合組成。
這些新領域模型的領域對象都源自原有的領域模型。不過，評級積分是經過重組產生的領域模型，原有的聚合會帶着各自的領域對象融入新的領域模型中。值得注意的是，根據新的業務要求，部分領域對象可能會從原聚合中分離出來，重新組合到其他聚合裏。
此外，新領域模型中的領域對象，如實體、領域服務等，在完成重組後，可能還需要依據新的業務場景和需求進行代碼重構。通過這樣的操作，能讓新領域模型更好地適應業務發展，爲企業的數字化轉型提供更有力的支持。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fuOEg55UnpuVKV7L7t7Bkw