,,

^{<blockquote id="sm8hu"></blockquote>}

領域驅動的事實與謬誤一 DDD 與 MVC

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

freeflydom

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

本文有以下幾個目的：

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

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

MVC到底在說什么

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

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

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

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

DDD到底在說什么

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

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

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

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

DDD與MVC并不沖突

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

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

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

DDD本來就不存在統一的代碼規范，原書也未給出具體實現手段

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

DDD的核心是什么？

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

代碼規范的真相 ：

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

領域層（Domain Layer）封裝核心業務邏輯，包含實體、值對象、聚合根；
應用層（Application Layer）協調領域對象，處理事務和權限；
基礎設施層（Infrastructure Layer）處理數據庫、消息隊列等技術細節。

爭議與選擇 ：

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

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