學習DDD的時候，作為開發，我們更關心它在技術層面的東西，尤其體現在DDD的分包方式、編碼技巧等方面。

自然的，我們不禁發問，用了DDD的分包，就是實踐落地了DDD了么？

不賣關子，直接說答案，并不是。

用了DDD的分包，只能說滿足了DDD的"形"，并沒有抓住DDD的"神"。DDD的神是什么，歸根到底還是面向對象，領域建模。所謂的各種分包方式本質上還是為了滿足DDD面向對象的本質,方便開發者進行代碼編寫而提供的一種"戰術設計"工具。

要深入討論這個問題,我們需要花一點時間來學習討論一下DDD中常見的幾種分包。

DDD分包概述

基于DDD的分包主要有兩大流派：分層架構以及六邊形架構。

分層架構以四層架構為主，基于四層架構又誕生出衍生的五層架構、六層架構等等(限于篇幅以及討論重點，本文中我們只討論四層架構)。

六邊形架構出自 Robert C Martin(沒錯，就是傳說中的鮑勃大叔)提出的整潔架構，后來者不斷探索，又衍生出了洋蔥架構。

這個過程可謂是百家爭鳴。實際開發中，最為我們熟知的當屬四層架構與六邊形架構了，其余的各種架構都是基于這兩種架構方式的變體。

四層分層架構

四層架構的分層如下圖：

從上往下依次為：

|-userinterface 用戶界面層/表示層|-application 應用層|-domain 領域層|-infrastructure 基礎設施層

我們對這幾層的主要功能逐個分析：

User Interface?為用戶界面層(或表示層)，負責為用戶做信息展示以及對用戶輸入的命令進行解釋與輸出。這里指的用戶可以是另一個計算機系統，不一定是使用用戶界面的人。

Application?為應用層，應用層主要提供了用例級別的功能。它定義了軟件要完成的任務，并且借助表達領域概念的對象來組織并解決問題，可以理解為通過膠水粘合了各種領域概念。這一層所負責的工作對業務來說意義重大，也是與其它系統的應用層進行交互的必要渠道。應用層要盡量簡單，它應當盡量不包含業務規則或者知識，而只負責協調下一層中的領域對象，為領域對象分配工作， 使它們互相協作。應用層反應不了業務情況的狀態，但是可以表達另外一種狀態，為用戶或程序顯示某個任務的進度。

Domain?為領域層(或模型層)，負責表達業務概念，業務狀態信息以及業務規則。盡管保存業務狀態的技術細節是由基礎設施層實現的，但是反映業務情況的狀態確實是由領域層控制并且使用的。領域層是業務軟件的核心，它體現了DDD的核心：領域模型。

Infrastructure?層為基礎實施層，它向其他層提供通用的技術能力：為應用層傳遞消息，為領域層提供持久化機制，為用戶界面層繪制屏幕組件，等等。基礎設施層還能夠通過架構框架來支持四個層次間的交互模式。

說完概念，還是不夠直觀表現DDD四層架構在實際開發中扮演的角色與包含的功能，稍安勿躁，我們舉幾個例子說明一下：

在實際開發中，User Interface層主要包含Restful消息處理/RPC 接口交互/消息消費入口，配置文件解析，等等。

Application層主要是多進程管理及調度，多線程管理及調度，多協程調度和狀態機管理，跨領域業務組織與交互(比如：對外調用的出口就可以在application進行體現，也就是所謂的防腐層)，等等。

Domain層主要是領域模型的實現，包括領域對象的確立，這些對象的生命周期管理及關系，領域服務的定義，領域事件的發布，等等。

infrastructure層主要是業務平臺，編程框架，第三方庫的封裝，基礎算法，等等，它為上層提供了技術層面的支持，且往往與具體的業務細節無關。

六邊形架構

六邊形架構也稱為端口與適配器架構，一個典型的六邊形架構如圖

六邊形每條不同的邊代表了不同類型的端口，端口要么處理輸入，要么處理輸出。對于每種外界類型，都有一個適配器與之對應，外界通過應用層API與內部進行交互。

上圖中有3個客戶請求均抵達相同的輸入端口(適配器A、B和C)，另一個客戶請求使用了適配器D。假設前3個請求使用了HTTP協議(瀏覽器、REST和SOAP等)，而后一個請求使用了AMQP協議(比如RabbitMQ)。

端口并沒有明確的定義，它是一個非常靈活的概念。無論采用哪種方式對端口進行劃分，當客戶請求到達時，都應該有相應的適配器對輸入進行轉化， 然后端口將調用應用程序的某個操作或者向應用程序發送一個事件，控制權由此交給內部區域。

應用程序通過公共API接收客戶請求，使用領域模型來處理請求。

我們可以將DDD戰術設計建模元素Repository的實現看作是持久化適配器，該適配器用于訪問先前存儲的聚合實例或者保存新的聚合實例。

正如圖中的適配器E、F和G所展示的，我們可以通過不同的方式實現資源庫，比如關系型數據庫、基于文檔的存儲、分布式緩存或內存存儲等。

如果應用程序向外界發送領域事件消息，我們將使用適配器H進行處理。該適配器處理消息輸出，而上面提到的處理AMQP消息的適配器則是處理消息輸入的，因此應該使用不同的端口。

這張圖是筆者從《微服務架構設計模式》中摘錄出來的

它通過OrderService表達了一個訂單服務，它的核心通過六邊形架構組織，由業務邏輯和一個或多個與其他服務和外部應用程序連接的適配器組成。

圖中，REST API Adaptor?：表示入站適配器，實現REST API，這些API會調用業務邏輯(其實就是傳統開發下的controller/api之類的勞什子，換了個馬甲就顯得高大上了)

OrderCommandHandlers：入站適配器，它接收來自消息通道的命令式消息，并調用業務邏輯(其實就是傳統開發下的消息消費者，比如Kafka中的listener之類的，沒什么新意)

Database Adaptor：業務邏輯調用以訪問數據庫的出站適配器。(好家伙，出站適配器，換了名字顯得十分陽春白雪， 按照下里巴人的理解，就是?相對業務邏輯而言，數據庫位于業務邏輯之外。因此持久化領域實體這操作，方向是由領域模型指向系統之外的，所以叫出站適配器)

Domain Event Publishing Adapter：將事件發布到消息代理的出站適配器(這其實就是傳統開發下的消息生產者，比如Kafka這種的Producer)之所以也是出站適配器，是因為消息發送到消息中間件后，相對業務邏輯而言，也是處于業務邏輯之外。

我們可以看到，六邊形架構中的出站適配器、入站適配器，一旦映射到傳統開發中的概念，都是我們日常開發中經常接觸到的。本質上還是換湯不換藥，不得不佩服軟件行業造詞的能力。

階段總結：四層架構與六邊形架構的對應關系

我們對上面的講解做一個小小的總結。

四層架構與六邊形架構，表面上看起來是不同的兩種架構分層方式，本質上，他們是同一事物的一體兩面， 是不同的思想對于同一個事物在不同時期思考總結的產物，雖然表象不同，但本質卻能夠收斂對應起來的。

具體是如何對應的呢？

DDD四層架構中UserInterface和infrastructure可以對應到六邊形架構中的適配器(入站和出站適配器均可，按照實際的角色具體分析對待)；

四層架構中的application能夠對應到六邊形架構中的應用程序層；

四層架構中的domain能夠對應到六邊形架構中的領域模型層。

了解了DDD四層架構和六邊形架構,我們又回到文章開頭的問題上來.

既然說DDD在架構分層上往往能夠通過四層架構、六邊形架構表達，那么我們用了四層架構/六邊形架構去做編碼，我們不就是落地了領域驅動設計了么？

文章的開頭我們直接給了回答，NO，用了分包并不代表落地了領域驅動設計。

我們經常聽到一個成語，“形神兼備”。

對于DDD而言，分包只是DDD的形，如果只是一味的套用DDD的分包，很容易重新回到傳統的三層架構中來，用俗話說就叫?“開倒車”，而這個過程常常伴隨著代碼腐化，最終會演化為《人月神話》中提到的?“焦油坑”。

再談DDD本質

這里，容我插一句與主題無關的話:

這個系列，雖然是針對DDD進行的，但是筆者卻不厭其煩的試圖去挖掘所謂的本質。原因在于不想將這個主題單純的寫成一個科普類的概念普及系列，如果是這樣的話，倒不如直接去看書來的更快更直接。

之所以不斷去強調DDD的本質，還是想以我的視角，去呈現一些我在學習DDD的過程中的一些思考，提供給讀者做參考，進而去努力使讀者在學習過程中避免浪費時間踩坑，更深層的意圖在于努力避免讀者進入學習的誤區。

好了，我們還是回到正題。

在之前的文章中，筆者也提到過：“DDD本質是面向對象為核心，通過領域建模還原現實世界”。

DDD作為一種指導復雜軟件設計開發的方法論，其根源還是基于面向對象思想，圍繞著對象本身的行為和屬性，為不同對象劃分邊界， 并規范約束了多個對象(所謂領域)分組間的通信/交互方式。

簡單的說，DDD的本質還是面向對象編程(不厭其煩，老生常談，希望你無論如何要記住這一點)，通過為對象注入有業務屬性的行為，還對象以血肉；以對象建模映射現實世界的具體業務場景和真實交互行為， 通過業務概念映射代碼邏輯，借助一整套的戰略設計與戰術設計，讓系統從流程化的貧血狀態機轉變為具有有序業務交互的充血引擎。

我們可以說，通過DDD指導建模，到最終落地的過程，就是將真實世界的業務場景映射為領域模型及其交互流程的過程。

學習DDD的時候，作為初學者總是容易陷入它那一整套復雜方法論之中，DDD自身的概念、所謂的戰略設計、所謂的戰術設計， 其本質都是為了方便開發者/領域專家/業務需求方統一溝通語言，并指導模型構建最終進行代碼落地的工具。

可以這么說，不論是戰術設計還是戰略設計，本質都是為了方便將真實世界映射到軟件模型中。

有了這樣的認知，再回過頭去學習了解戰略設計、戰術設計及其衍生概念，就會更加容易。

如果只想記住一句話，那么只需要知道：DDD其實是一系列面向對象軟件設計建模的方法論集合，其本質還是面向對象編程，其根本目的在于更加系統化指導復雜軟件建模與落地，更好的將現實世界的復雜業務場景抽象為有序簡潔易維護的軟件系統。

當然，開發簡潔有序易維護的軟件系統，只用DDD是遠遠不夠的，還需要有豐富的工程思想、整潔架構思想、扎實的編碼功底、系統的軟件工程理論等共同作用，這也是DDD這套方法論一直在發展的方向，它不斷吸納其他良好的最佳實踐為己用，不斷擴展邊界。時至今日，DDD已經是涵蓋建模、開發、測試、管理等領域的綜合軟件開發指導理論與思想。

正本清源，萬法歸宗

DDD的分包方式是領域建模的結果在代碼分層上的映射，只是解決了“代碼編寫完成之后往哪里放”的問題，

我們甚至可以大膽的斷言，

即便不采用DDD的分層，還是基于原有的 nterface->service->domain->dao的分層，只要基于面向對象分析建模，

最終落地的代碼他和DDD建模的結果也會殊途同歸，因為

問題的根本其實還是在于領域如何劃分，領域之間如何進行交互的問題。

下期預告

接下來的文章中，我們將正式進入戰術設計/戰略設計中，不同于書籍，筆者會通過一個電商中的營銷/支付/記賬的業務場景，通過實戰與概念穿插的方式，去進行內容的呈現。

以馬克思主義為指導，通過理論與實踐相結合，真正將DDD落地到實戰中去。

總結

以上是生活随笔為你收集整理的ddd 企业应用架构模式_灵魂拷问:用了DDD分包就是落地了领域驱动设计吗?谈谈DDD本质...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。