#頭條創作挑戰賽#
引言
前面幾篇文章中，筆者給大家闡述了 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 的魅力所在。