領域驅(qū)動的事實與謬誤一 DDD 與 MVC

當前位置：點晴教程→知識管理交流 →『技術文檔交流』

freeflydom

2025年5月7日 9:12 本文熱度 124

本文有以下幾個目的：

讓新手少交智商稅，少浪費時間看一些軟文。
普及一個基本概念：了解一項觀點的提出年代和最初初衷，才能更好地掌握其精粹。
我想指出市場上一些誤人子弟的軟文。

首先說明：文中所說的謬誤并非原書的謬誤，而是很多網(wǎng)上水軍寫的軟文在不斷誤人子弟、傳播錯誤認知。

MVC到底在說什么

??MVC（Model-View-Controller）架構由挪威計算機科學家Trygve Mikkjel Heyerdahl Reenskaug于1979年在施樂帕克研究中心（Xerox PARC）訪問期間提出。這一架構最初是為Smalltalk編程語言設計的，旨在解決圖形用戶界面（GUI）開發(fā)中數(shù)據(jù)管理與用戶交互的復雜性問題。當時Smalltalk的GUI需要支持動態(tài)交互（如用戶操作實時更新數(shù)據(jù)），傳統(tǒng)單體架構難以維護，MVC通過解耦輸入-處理-輸出流程，首次實現(xiàn)了界面與邏輯的分離。

??Reenskaug認為，GUI應用需要將不同功能模塊解耦，以應對數(shù)據(jù)復雜性和用戶交互的動態(tài)性。他提出將軟件系統(tǒng)劃分為三個核心組件：

模型（Model） ：封裝數(shù)據(jù)和業(yè)務邏輯，獨立于界面展示，例如數(shù)據(jù)庫結構或業(yè)務規(guī)則。
視圖（View）：負責用戶界面的呈現(xiàn)，直接與用戶交互，例如窗口、按鈕等可視化元素。
控制器（Controller）：協(xié)調(diào)模型與視圖的交互，處理用戶輸入并更新模型狀態(tài)，例如按鈕點擊后的邏輯判斷。

??MVC的Model本身包含基礎業(yè)務邏輯（如數(shù)據(jù)驗證），但復雜業(yè)務場景下需獨立的應用邏輯層（如Service層）來組織流程，這與DDD的領域建模形成互補。因此，四層架構（Model-View-Controller-Service）的出現(xiàn)是企業(yè)級開發(fā)的演進，而非MVC原生缺陷。

DDD到底在說什么

??DDD由Eric Evans 在2003年出版的經(jīng)典著作《領域驅(qū)動設計：軟件核心復雜性應對之道》中系統(tǒng)提出。其誕生源于對復雜業(yè)務系統(tǒng)開發(fā)困境的反思：

傳統(tǒng)開發(fā)的痛點：
- 軟件模型與真實業(yè)務領域脫節(jié)，導致需求頻繁變更時難以維護；
- 技術團隊與領域?qū)＜遥ㄈ鐦I(yè)務分析師、行業(yè)專家）溝通低效，術語不統(tǒng)一，模型設計偏離實際業(yè)務邏輯；
- 當業(yè)務復雜度高（如金融、供應鏈、醫(yī)療等領域）時，傳統(tǒng)開發(fā)方法（如數(shù)據(jù)驅(qū)動設計、貧血模型）無法有效管理復雜性，代碼逐漸淪為"意大利面條"。
核心目標 ：

Evans認為，應對復雜業(yè)務系統(tǒng)的關鍵在于將領域知識作為設計的核心，通過建立清晰、準確的領域模型，讓技術實現(xiàn)緊密貼合業(yè)務本質(zhì)，從而提升系統(tǒng)的可維護性和擴展性。

- 戰(zhàn)略設計：通過限界上下文（Bounded Context）劃分業(yè)務邊界，明確領域模型的適用范圍（如電商中的"訂單域"與"支付域"），解決業(yè)務與技術對齊問題；
- 戰(zhàn)術設計：通過實體、值對象、聚合根等工具實現(xiàn)領域模型，確保業(yè)務規(guī)則封裝在代碼中。

DDD與MVC并不沖突

??在傳統(tǒng)MVC架構下，解決GUI問題時，我們會設計GUI層面的技術模型，再根據(jù)模型渲染界面。同理，解決業(yè)務邏輯問題時，也可以設計一個領域模型，再基于模型開發(fā)業(yè)務邏輯。

??從圖中不難看出：領域驅(qū)動設計的核心是教你如何設計業(yè)務邏輯, 注意，是"業(yè)務邏輯設計"，而非技術分層設計。原因很簡單：DDD原書明確指出，這不是一本教你寫代碼的書，而是教你如何應對復雜軟件的方法論。

??無論哪個層面的技術開發(fā)，都可以先建模，再基于模型開發(fā), 這是幾乎所有行業(yè)都在使用的通用手段。

DDD本來就不存在統(tǒng)一的代碼規(guī)范，原書也未給出具體實現(xiàn)手段

??回到上圖，你會發(fā)現(xiàn)：任何一個技術維度的修改，都不需要其他維度的直接支持，甚至可以單獨調(diào)整某個維度------這正是DDD在戰(zhàn)術設計上想表達的理念。但這部分內(nèi)容被放在原書的最后章節(jié)，不僅因為前面的章節(jié)是前提，更因為代碼架構并非DDD的核心。

DDD的核心是什么？

統(tǒng)一語言：團隊（包括業(yè)務專家）使用一致的術語描述業(yè)務規(guī)則（如"訂單已支付"對應領域事件）；
領域模型：圍繞業(yè)務概念設計代碼，而非圍繞數(shù)據(jù)庫或技術框架；
解耦思想：通過聚合根、倉儲等模式隔離業(yè)務邏輯與技術細節(jié)。

代碼規(guī)范的真相 ：

??DDD不強制規(guī)定具體代碼結構和命名，但業(yè)界基于實踐形成了通用分層原則（如四層架構：表現(xiàn)層、應用層、領域?qū)?、基礎設施層）。例如：

領域?qū)樱―omain Layer）封裝核心業(yè)務邏輯，包含實體、值對象、聚合根；
應用層（Application Layer）協(xié)調(diào)領域?qū)ο?，處理事務和權限?/li>
基礎設施層（Infrastructure Layer）處理數(shù)據(jù)庫、消息隊列等技術細節(jié)。

爭議與選擇 ：

??業(yè)界關于代碼結構的最大爭議是按功能分包 vs 按技術層分包：

按功能分包（如order/ user/）利于業(yè)務模塊隔離，適合大型復雜系統(tǒng)；
按技術層分包（如controller/ service/）便于技術棧管理，適合中小型項目。兩者無絕對優(yōu)劣，需結合團隊規(guī)模和業(yè)務復雜度選擇, 但是無論如何每一個項目團隊都應該做的，就是對業(yè)務進行建模分析，對團隊開發(fā)形成整齊劃一的技術規(guī)范。