DDD 助力平臺能力複用

系統爲何會變複雜

不確定性是互聯網業務發展的主旋律，產品與業務每天都在迭代，研發團隊需要面對這種不停的變化，應對這種變化最好的方式就是主動進化。

面對變化，研發團隊需要有這樣一個共識，需求是易變的，需求點是不精確的，代碼是會腐化的，老闆是想要多快好省的。

技術同學能做的就是，如何在以上這些點上做平衡取捨，當某一個或者某幾個變量出現時，我的系統可以快速擴展應對和彈性應對。

背後還是分離術，哪些本質的東西是不變的，我們深挖它，哪些是易變的，我們想法屏蔽變更復雜度。

領域驅動方法論

談到業務複雜度治理，最火的就是 DDD 了，通過 DDD 背後的治理方法論，可以有效的分離業務和技術複雜度，使得領域層代碼和領域模型保持高度一致。

爲實現這種一致，就要求所有需求的參與者（研發 / 產品 / 運營）對於這個業務的建模 / 模型 / 設計的理解是一致的，是有共識的，這樣才能實現分析模型與設計模型不再割裂。

結合我個人經驗，一個大型平臺系統複雜度提升無外乎兩個方面導致的：系統業務緯度與系統技術緯度。

所以在通過 DDD 做系統複雜度治理時，可以從這兩個方向入手。

架構抽象來說是由元素及元素之間的關係組成的。

所以元素數量越多越複雜，比如代碼規模，關係越亂越複雜，比如層級套用 / 遞歸等。

技術複雜度來源於系統對於穩定性的追求，比如代碼質量 / 高可用 / 高性能 / 安全性 / 高病房 / 擴展性等。很多人在面對這些選項時無從下手，主要表現爲，不知如何控制代碼及系統複雜度，不知道如何讓服務 / 模塊具有擴展性和彈性，不知道是代理好還是直連好，數據層怎麼做預熱 / 異構 / 加工等。當一個複雜的核心鏈路上多個系統有不同的技術要求時，如何取捨做好架構就更懵逼了。

我解決不好我就不去解決就可以了，所以在 DDD 中首先的一個思想就是，剝離業務邏輯細節與技術實現細節。首先劃定一個業務邏輯與技術邏輯的邊界，從而隔離各自的複雜度。技術層的技術迭代不會影響業務，業務的擴展也不受技術的制約。

DDD 裏面體現這種剝離是由六邊形架構實現的。

所以在 DDD 落地過程中，最重要的一點就是充分交流 / 提煉知識點 / 獲取問題域 / 劃定上下文邊界 / 識別核心域與其他子域，這樣一步步的將一個複雜的業務場景問題，拆成細粒度的，獨立且內聚的子系統，實現目標聚焦，進而實現了複雜度可控。

除了六邊形架構，在 DDD 中還有哪些可以直接借鑑的架構劃分模式呢？

六邊形架構

清晰界定技術邊界與業務邊界；

CQRS 分離了查詢場景和命令場景，讓同步與異步成爲了可選，實現了低延遲與高併發的不同要求。

分層架構

將關注點以分層的形式剝離，不同的業務邏輯關注點放在不同的層裏面。

戰略設計與戰術設計

DDD 設計主要分爲兩個過程：戰略設計與戰術設計。

戰略設計

一般是領域專家通過充分溝通，事件風暴或者場景分析，分析需求提煉知識點，得到清晰問題域，輸出 UL。

在基於 UL 繼續進行問題域分析與建模，進而識別業務邊界，確定限界上下文，之後根據限界上下文劃分成不同的獨立域。

在引入系統上下文實現系統與外部環境的銜接。

戰術設計

戰術設計是深入問題域，專注於一個領域的實現，依賴面向對象思想，專注聚焦於某個內聚的限界上下文中，對模型進行分解與建模。

領域驅動設計強調和突出了領域模型的重要性，通過整個領域驅動設計過程，綁定領域模型和技術模型，以保證領域模型和技術模型在貫穿整個軟件開發的生命週期中（需求分析、建模、架構、設計、編碼、測試與持續重構）的強一致性。領域模型指導着軟件設計以及技術編碼實現，接着通過重構實踐來挖掘隱式概念，完善統一語言和模型，運用設計模式改進設計與開發質量。以下是領域驅動設計的粗略過程：

識別限界上下文

明確了系統的問題域和業務期望後，梳理出主要的業務流程，這些業務流程體現了各種參與者在這個過程中通過業務活動共同協作，最終完成具有業務價值的領域功能。

業務流程結合了參與角色（Who）、業務活動（What）和業務價值（Why）。

在業務流程的基礎上，我們就可以抽象出不同的業務場景，這些業務場景又由多個業務活動組成，可以利用領域場景分析方法剖析場景，以幫助我們識別業務活動，例如採用用例對場景進行分析，此時，一個業務活動實則就是一個用例。業務流程是一個由多個用戶角色參與的動態過程，而業務場景則是這些用戶角色執行業務活動的靜態上下文。

從不同角度看待限界上下文，限界上下文會呈現出對不同對象的控制力：

• 領域邏輯層面：限界上下文確定了領域模型的業務邊界，維護了模型的完整性與一致性，從而降低系統的業務複雜度。

• 團隊合作層面：限界上下文確定了團隊的工作邊界，建立了團隊之間的合作模式，提升了團隊間的協作效率，“康威定律” 告訴我們，系統設計（產品結構）等同組織形式，每個設計系統的組織，其產生的設計等同於組織之間的溝通結構，限界上下文指導產生的團隊結構的工作模式是最高效的。

• 技術架構層面：限界上下文確定了系統架構的應用邊界，保證了系統層和上下文領域層各自的一致性，建立了上下文之間的集成方式。微服務中，限界上下文指導技術人員劃分微服務的邊界，通常一個限界上下文作爲一個在獨立進程中運行的微服務。

與中臺關係

利用 DDD 提倡的分層、六邊形等架構，分離了業務複雜度和技術複雜度，使得系統具備更強的擴展性和彈性；戰術層面提供了元模型（聚合，實體，值對象，服務，工廠，倉儲）幫助構建清晰、穩定，能快速響應變化和新需求能力的應用；

DDD 構建的應用能快速方便地切到微服務；領域驅動設計給企業應用帶來的穩定性、靈活性、擴展性和應對變化的響應力對於建立靈活前臺、穩固中臺能帶來巨大的幫助作用。

分治思想搭建技術框架

我們架構上的經驗，遇到複雜問題是最好的方式就是分治，可以將現有平臺系統拆成兩部分：

• SDK：前端 SDK 負責實現開放能力

• 數據源服務：後端數據源 & 服務

• 流程畫布：靈活強大的流程畫布

• 移植部署流程：快速移植和部署到任何三方 IT 環境的方案能力

這樣的分發其實適用於很多平臺型系統的技術框架，通過這種分治可以實現業務複雜度控制，同時具備極強的擴展性和彈性。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5s-t9qe4gxpgufofrl7whg