98久久久久久久久久,日韩一级久久久

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

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

freeflydom

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

本文有以下幾個目的：

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

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

MVC到底在說什么

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

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

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

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

DDD到底在說什么

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

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

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

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

DDD與MVC并不沖突

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

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

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

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

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

DDD的核心是什么？

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

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

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

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

爭議與選擇 ：

??業(yè)界關(guān)于代碼結(jié)構(gòu)的最大爭議是按功能分包 vs 按技術(shù)層分包：

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