DDD 領域驅動設計落地實踐系列：工程結構分層設計

引言

前面幾篇文章中，筆者給大家闡述了 DDD 領域驅動設計的三大程序，重點圍繞如何通過戰略設計與戰術設計進行 DDD 落地實踐進行了詳細的討論，但是還沒有涉及到工程層面的落地，實際上所有的這些架構理論到最后都是為了使得我們代碼結構更加清晰，從而開發出 bug 少、擴展性強、邏輯清楚的應用，因此本文就是為了解決 DDD 領域驅動落地實踐最后一公里問題，將我們分析出來的領域模型通過與工程結構的映射實作真正的落地，

DDD 領域分層

當我們完成領域模型構建之后，我們需要先確定下微服務內部的領域分層結構，因為這個領域分層的好壞直接決定了我們微服務的工程結構是否合理，呼叫邏輯是否清晰，而這些領域模型都需要映射到實際的代碼，我們開發的代碼到底應該放在哪一層，放在哪些目錄中，都需要依托于領域封層的結果，但是真正的領域驅動設計在怎么規范代碼結構上面實際也沒有具體的規范，因此我們需要根據自己的實踐經驗以及思考進行劃分，

分層的目的實際上就是讓各層的邏輯可以分工協作、各司其職，避免不必要的代碼互相污染，同時結構清晰的分層結構也比較便于后期的重構以及拆分或者合并，實際上也是一種在為未來可能存在的變化節省研發成本，

這里需要說明的是，在傳統的領域分層中，是將基礎設施層作為其他三層的依賴的，但是實際上這種方式是有問題的，為什么這么說呢？因為如果我們真的按照用戶介面層、應用層以及領域層都依賴基礎設施層的話，那基礎層就成了最核心的層級了，但是實際上領域層才是真正的核心，這顯然違背了 DDD 以領域為核心的設計思想，因此我們使用依賴倒置的方式，讓基礎設施層去依賴領域層，這樣做的好處就是可以讓領域層更加的職責單一以及更加的純粹，他不需要關心資料是怎么來的，無論是資料庫查來的還是快取萃取出來的還是從外部查來的，它只需要關心它自己領域內的業務邏輯就可以，既然我們明確了該怎么進行領域分層，那么各層的資料組織形式是怎樣的呢？

各層資料物件

VO（View Object，視圖物件）：該層的視圖資料物件主要的作用就是將應用層的資料進行組裝后形成用于頁面展示的視圖資料，

DTO（Data Transfer Object，資料傳輸物件）：DTO 主要作為 Application 層的入參和出參，用于用戶介面層與應用層之間的資料傳輸，

Model（領域物件）：領域物件是我們正常業務應該用的領域業務模型，它的欄位和方法應該和業務語言保持一致，不需要進行持久化和序列化，他主要存在與記憶體中，也就是說，所以 Model 和 DO 可能欄位屬性都不一樣，

DO （Data Objec，資料物件）：一般都是使用 PO 作為持久化的資料物件，但是筆者習慣使用 DO，因為我覺得資料物件當然要和資料庫中的欄位相對應的，因此從名稱來說，DO 作為持久化物件我想更加合適一點，

資料流轉

上文中分別說到了領域分層結構以及各個資料物件的不同含義和用途，那么我們接下來就看下各個資料物件在 DDD 的各個領域分層中是怎么進行資料流轉的吧，

在用戶介面層，它需要接收來自 WEB 端、APP 端以及其他的外部資料請求，并將請求通過 DTO 向應用層進行傳遞，根據應用層回傳的 DTO 資料，再將 DTO 轉化為頁面需要呈現的 VO 資料，進行最后的頁面展示，

當請求到達應用層后，如果需要呼叫外部服務的介面，那么我們需要通過應用層的防腐層進行呼叫，那么為什么需要防腐層進行呼叫而不是直接呼叫呢？主要的原因就是為了隔離介面資料變化，防止外在服務的資料變化影回應用層的代碼，如果真的需要修改那么直接在防腐層中進行修改就好了，

在領域層，我通常使用的是 model，可以理解為業務領域模型，主要包括物體以及值物件，在應用層會將 model 作為引數進行領域層介面的呼叫完成核心的業務邏輯，在一些其他的書中，很多人喜歡使用 DO 來作為領域層的資料承載物件，但是我個人還是覺得 model 更適合，因為從名稱上面更好理解一點，更加直觀一點，一看就知道是模型，什么模型，當然是業務的領域模型，

領域層中包含了倉儲的介面，具體的實作在基礎層中，這是一種依賴倒置的設計方式，實作領域層與基礎層的解耦，其他的書中喜歡使用 PO 作為這層的資料載體，我習慣使用 DO，因為 DO 就是資料物件，天然的和資料庫應該對應在一起，筆者同樣覺得這樣更加直觀，具體怎么用還是看各位在實際落地使用的時候的習慣吧，

領域模型與代碼模型映射

工程分層

如上圖所示，我們在微服務拆分后，將微服務內部的代碼層級主要分為 interfaces、biz、domain 以及 instructure 這四層，分別對應用戶介面層、業務層、領域服務層以及基礎設施層，注意這里的 biz 層實際就是 application 層，用為筆者覺得 application 層不好理解，而 biz 層更好理解一點，實際他們的功能是一樣的，只是為了減低下理解的成本，

interfaces 層：就是用戶介面層，這里主要存放一些與前端互動的代碼以及與其他服務互動的介面，主要的作用將將前端請求轉化為適當資料去呼叫 biz 層的業務代碼進行業務請求，另外將 biz 層回傳的資料進行組裝最終形成頁面所需要的資料，

biz 層：其實就是 application 層，但是我更愿意叫 biz 層，因為這層的作用實際就是進行服務組合以及服務調度的，實際它是基于下層的領域服務去完成業務邏輯流程的，因此我覺得叫 biz 層更加貼切一點，

domain 層：這是整個微服務的核心層，主要包含了領域模型、領域服務以及核心的業務邏輯，領域模型主要包括了聚合中的聚合根、物體以及值物件，領域事件也會放在這一層中，

instructure 層：基礎設施層主要包含了各種通用能力以及工具類，它的作用就是為上層提供基礎服務的，如資料庫服務、MQ 服務以及快取服務等還有其他的一些配置以及資源，

代碼歸位

1、interfaces 層
（1）assemble 主要負責實作 vo 與 dto 之間的資料轉換作業，

（2）vo 存放需要呈現在頁面的視圖資料物件，

（3）facade 主要實作本層的介面封裝，

2、biz 層
按照我自己的習慣，筆者是按斬訓粉的領域來進行包構建的，比如這里的 user 以及 authority 就是不同的領域，為什么這么劃分呢？主要考慮到未來萬一有新的拆分，我們可以直接按照對應的域進行拆分，效率要比在不同包中一個一個類找相關的高的多，另外按照領域劃分也比較清晰，可以方便的熟悉業務，

（1）dto 中主要放了資料傳輸物件，biz 層介面的入參以及回傳值都是 dto，

（2）service 就是 biz 的介面以及介面實作，主要的作用就是實作對于領域服務的編排以及組合，從而完成具體的業務流程，

（3）event 主要放的是事件發布以及訂閱的相關代碼，實際具體的事件核心邏輯可以放在 domain 層中進行處理，

3、domain 層
說實話，以前我們經常使用以資料驅動的設計以及開發方式，大部分的業務邏輯都是在 biz 層完成的，但是領域驅動設計和資料驅動設計最大的不同就是，大部分核心的業務邏輯需要下沉到 domain 層中，實際一開始進行這種方式的開發的時候非常的不習慣，但是當你實際沉下心來做的時候會發現，的確這種開發方式更加的能體現 DDD 的優勢，另外這里還是根據領域進行劃分，和 biz 層是一樣的，

（1）event 主要放事件處理的核心邏輯代碼，

（2）model 中就是具體的物體，

（3）repo 主要存放持久化的代碼，

（4）service 主要存放領域服務的核心業務邏輯代碼，

（5）valueobject 主要存放值物件，

4、instructure 層
這層的話主要存放一些基礎中間件的鏈接配置代碼以及 domain 的 repo 實作代碼以及其他一些資源類的代碼

總結

DDD 領域建模設計的理論中并沒有對在工程結構怎么落地實際的代碼做出硬性規定，本文主要根據筆者自己的一些思考以及實踐經驗梳理了領域模型與代碼模型映射的結構，希望對大家再各自業務落地 DDD 實踐的時候有所參考，到這里我們實作 DDD 落地的所有準備作業都差不多了，后面的文章中我們將根據真實的業務場景進行真正的落地實踐，從業務分析到領域建模，從領域分層到代碼實作，我想通過這一系列的理論加實踐的方式，相信大家可以真正領悟到 DDD 的魅力所在，

大家好，我是慕楓，感謝各位小伙伴點贊、收藏和評論，文章持續更新，我們下期再見！
微信搜索：慕楓技術筆記，優質文章持續更新，我們有學習打卡的群可以拉你進，一起努力沖擊大廠，另外有很多學習以及面試的材料提供給大家，最近在派送年終福利，趕快來看看吧，

真正的大師永遠懷著一顆學徒的心