【51CTO.com原創稿件】隨著微服務理論的盛行，沉寂了近二十年的 DDD 領域驅動設計的價值逐漸被越來越多的公司認可。

[[437058]]

圖片來自 包圖網

但是 DDD 作為純方法論，在實際應用中因缺乏類似框架的強約束性，如何有效指導業務落地實施，尤其是復雜系統架構的優化改造，都對研發團隊提出很高的要求。

采購平臺則通過溯源演進重放的方法，以“上帝視角”重新審視整個系統架構和業務發展的歷程以及重要節點，以演進重放的方式進行領域模型設計。

一方面使復雜系統改造有了很好的切入點，另一方面使系統設計天生具備演進屬性，適應當下業務的同時也能更好的兼容未來業務的發展。

根據熵增定律，一切事物如果不加以約束都趨向從有序變為無序。系統作為一個獨立個體，其熵增趨勢也是無法避免的。

業務的橫向拓展和縱向深耕，架構演進和技術創新都會導致系統復雜性越來越高。

畢竟個人的認知和接受能力是有上限的，當系統的復雜性超出團隊大多數人的認知上限時，系統的任何一點微小的優化或改動，都會讓研發團隊疲于奔命，也會給系統的穩定性帶來很大的風險或隱患!

所以提升開發效率和系統穩定性成為技術研發團隊繞不開且必須解決的問題。

事件

通過對采購平臺系統發展歷程和重要節點的不斷審視，發現導致系統復雜性的主要原因還是業務的復雜性。

系統架構設計中如果不能很好的解決業務領域的復雜性，技術架構的優化和演進再好也于事無補。

采購平臺自 15 年搭建伊始，業務橫向方面從最初單一的電器業態，逐步拓展紅孩子，百貨再到近幾年的小店，迪亞，家樂福等大快消業態。同時縱向對電器業態的深耕，如樣機，不良品，換異型等也在同步進行。

業態，操作模式，經營模式，業務模式等等相互穿插組合帶來了業務的靈活多變的同時，也帶來系統復雜度幾何級上升。

此時高效的開發效率更是無從談起，很難對業務的發展提供高效支撐，隨之而來的業務的埋怨和領導的不理解也給開發團隊帶來很大的心理負擔，進而影響團隊穩定性……環環相扣陷入惡性循環的泥潭。

如何破開困境?倡導保持概念完整性的領域驅動設計是個不錯的選擇。DDD 關注于精簡的業務模型和實現的匹配，其作為方法論指導系統架構設計，是解決業務領域復雜性的利器。

通過領域驅動設計模式促使研發團隊將業務模型作為項目溝通的核心，使成員之間更容易理解彼此之間的工作，大大提升團隊溝通效率。

領域模型的高內聚低耦合，大大降低不同業務模塊之間的影響有效提升系統穩定性，同時領域驅動設計倡導概念完整性，注重模型和實現的匹配使系統更易于理解和擴展。

挑戰點(難點)

雖然領域驅動設計是個不錯的指導方法論，也正因為是通用的理論，在具體項目的落實中，因不存在相同業務的系統，即使相似業務的系統因規模和產品生命周期差異，也只有一般意義上的參考價值。

所以都需要面臨如何進行領域建模的快速切入，以及預防模型在實現層面的腐化等諸多挑戰點。

主要體現在以下幾個方面：

①邏輯復雜，無從下手。系統經過日積月累的迭代優化，新的業務模塊和功能點與日俱增，且成發散趨勢。

再加上即使同業態下業務的深耕也有很多個性化需求，功能點相互穿拆耦合的現象非常普遍，千頭萬緒很難梳理。需要有個適合自身業務，行之有效的方法去指導辨別合適的切入點。

②能力差異，邊界難定。領域驅動設計使開發團隊從面向數據庫編程轉為面向領域編程，一切都要求從業務角度出發，對團隊成員業務理解能力要求大大提升。

實際上團隊成員的能力總是有差異的，其導致的理解偏差最終會逐漸反應到實現層，進而影響整個業務領域藍圖。

特別是在領域邊界的建立，模糊的有交集的領域模型，最終會腐化整個架構。這就需要有契合業務特性，簡易的界定方式，幫助團隊成員快速清晰的確認領域邊界。

③業務細化，粒度難分。明確了領域范圍也就是限界上下文，業務域做了合理的劃分也不代表領域驅動設計就會水到渠成。

隨之業務發展，原業務域或者子域可能又出現垂直細分的需求，細分的業務概念是否需要反應到業務領域藍圖也是一個需要重點考慮的問題。

業務概念的完整性和模型精簡之間權衡的度的把握，同樣需要有個簡單易行的標準。

分析與解決過程

針對上述問題，主要分析和解決方案對應如下：

①以始為本，回放演進

任何復雜的事物都是從簡單演化出來的，復雜的系統亦然?？v覽采購平臺的演進歷程，系統搭建初期，無論是業務模式還是系統規模都是最簡單和最小的。

所以通過復盤溯源的方式以系統搭建初期業務和系統規模為基線，進行初始化領域模型搭建更具可行性。

一方面業務規模小，更容易梳理出業務主線。加上初期各業務域之間很少或不存在交叉情況，建立領域模型相對簡單也方便入手。

另一方面初始領域模型建立后，再以業務和系統的實際的演變過程對初始領域模型進行豐富和優化，最終形成一個邊界清晰的完整的業務領域藍圖。

這一切都是在復盤過往業務發展和系統演進的基礎上進行的，貼合了業務和系統的發展曲線。

從概率的角度上看，用該方法完善的領域模型比單純依靠經驗而建的模型更能好的契合當前業務發展和兼容未來業務的變化。同時以上也都符合一個好的架構的“簡單，合適，演進”特征。

②作用范圍，領域定界

提及領域驅動設計離不開“核心域”“聚合根”“實體”“值對象”“限界上下文”等，DDD 的各類文檔資料對上述名詞都有很明確的定義和解釋。

但是實際項目的落實中，仍然需要一個簡易可行的界定方法，為領域驅動設計在團隊內部實施和演進掃清障礙。

“易則易知，簡則易行”簡易可行的方法才能更容易被團隊成員理解和接受。

結合采購平臺本身的業務特性，將采購執行鏈路上產生的各種類型單據以及交互進行梳理，如訂單，預約單，作業指令，收發貨等實體化后作為一個對象，以此對象作為聚合根，凡是以該對象為主體的作用范圍都歸于一個領域。

一旦該對象在某個環節的業務邏輯中失去“主角”光環，則需要根據實際業務確定新的“主角”進而決定是新建領域還是轉到已存的別的領域。

③維度固化，細化剝離

維護業務概念的完整性是衡量設計好壞的一個重要的參考指標。好的設計從代碼層面清晰展現業務領域藍圖且易于理解，同時又能很好的隔離不同領域相互之間的影響。

實際項目中往往存在很多因業務需要在某一場景下進行細分的情況，按照維護業務概念完整性的要求就需要將細分場景進一步獨立進行隔離解耦。

但過多的細分場景增加了開發工作量也模糊了業務領域藍圖，同時加深了對業務整體的溝通和理解難度。

如采購平臺實際的收發貨業務場景，最初根據業務分類按照采購入庫，退廠出庫，調撥出庫，調撥入庫等進行分類場景處理。

后期隨著業務的拓展，采購入庫場景下進一步按類型維度細分出換異型入庫，不良品返廠維修入庫等完全個性化的處理邏輯。

根據鏈路上下游系統交互情況，以及團隊內部對該業務域的認知，權衡后確定的原則是，以收發貨業務分類進行領域藍圖的展現，以此作為該業務域下維護概念完整性的唯一且不變的維度。

特定業務分類下進一步按類型細化場景，作為一個子域，業務也獨立并以策略模式歸集于上一層的業務分類領域。

方法論(正向)

領域驅動設計作為指導架構設計的一種有效思想，對復雜邏輯的業務系統的重構和建設提供了很好的解決方案。

但再好的設計也必須通過實現層展現，實現層質量又嚴重依賴開發團隊的個人能力。

“簡易可行，契合業務”的方法和原則還是很有必要的，這是設計推行和架構防腐的很有效的手段。

但同時也要看到領域驅動設計并不是解決系統復雜性的銀彈。對癥則是良藥，為了 DDD 而 DDD 則可能最終變成毒藥。

作者：胥磊

簡介：蘇寧易購供應鏈 BU 采購管理研發中心采購中臺技術負責人，對復雜業務系統架構的優化和拓展有一定的經驗。前后負責過蘇寧采購平臺的搭建，向采購中臺演進以及 DDD 改造的技術架構設計。

編輯：陶家龍 

征稿：有投稿、尋求報道意向技術人請聯絡 editor@51cto.com

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】