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

{"type":"doc","content":[{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"引言","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"前面幾篇文章中，筆者給大家闡述了DDD領域驅動設計的三大過程，重點圍繞如何通過戰略設計與戰術設計進行DDD落地實踐進行了詳細的討論，但是還沒有涉及到工程層面的落地。實際上所有的這些架構理論到最後都是爲了使得我們代碼結構更加清晰，從而開發出bug少、擴展性強、邏輯清楚的應用。因此本文就是爲了解決DDD領域驅動落地實踐最後一公里問題，將我們分析出來的領域模型通過與工程結構的映射實現真正的落地。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"DDD領域分層","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當我們完成領域模型構建之後，我們需要先確定下微服務內部的領域分層結構，因爲這個領域分層的好壞直接決定了我們微服務的工程結構是否合理，調用邏輯是否清晰。而這些領域模型都需要映射到實際的代碼，我們開發的代碼到底應該放在哪一層，放在哪些目錄中，都需要依託於領域封層的結果。但是真正的領域驅動設計在怎麼規範代碼結構上面實際也沒有具體的規範，因此我們需要根據自己的實踐經驗以及思考進行劃分。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/0d/0d5b8f34dd307cecdaf85e8443186fff.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"分層的目的實際上就是讓各層的邏輯可以分工協作、各司其職，避免不必要的代碼互相污染。同時結構清晰的分層結構也比較便於後期的重構以及拆分或者合併，實際上也是一種在爲未來可能存在的變化節省研發成本。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這裏需要說明的是，在傳統的領域分層中，是將基礎設施層作爲其他三層的依賴的，但是實際上這種方式是有問題的。爲什麼這麼說呢？因爲如果我們真的按照用戶接口層、應用層以及領域層都依賴基礎設施層的話，那基礎層就成了最核心的層級了，但是實際上領域層纔是真正的核心，這顯然違背了DDD以領域爲核心的設計思想。因此我們使用依賴倒置的方式，讓基礎設施層去依賴領域層，這樣做的好處就是可以讓領域層更加的職責單一以及更加的純粹，他不需要關心數據是怎麼來的，無論是數據庫查來的還是緩存萃取出來的還是從外部查來的，它只需要關心它自己領域內的業務邏輯就可以。既然我們明確了該怎麼進行領域分層，那麼各層的數據組織形式是怎樣的呢？","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"各層數據對象","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"VO（View Object，視圖對象）","attrs":{}},{"type":"text","text":"：該層的視圖數據對象主要的作用就是將應用層的數據進行組裝後形成用於頁面展示的視圖數據。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"DTO（Data Transfer Object，數據傳輸對象）","attrs":{}},{"type":"text","text":"：DTO主要作爲Application層的入參和出參，用於用戶接口層與應用層之間的數據傳輸。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"Model（領域對象）","attrs":{}},{"type":"text","text":"：領域對象是我們正常業務應該用的領域業務模型，它的字段和方法應該和業務語言保持一致，不需要進行持久化和序列化，他主要存在與內存中。也就是說，所以Model和DO可能字段屬性都不一樣。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"DO （Data Objec，數據對象）","attrs":{}},{"type":"text","text":"：一般都是使用PO作爲持久化的數據對象，但是筆者習慣使用DO，因爲我覺得數據對象當然要和數據庫中的字段相對應的。因此從名稱來說，DO作爲持久化對象我想更加合適一點。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"數據流轉","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"上文中分別說到了領域分層結構以及各個數據對象的不同含義和用途，那麼我們接下來就看下各個數據對象在DDD的各個領域分層中是怎麼進行數據流轉的吧。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在用戶接口層，它需要接收來自WEB端、APP端以及其他的外部數據請求，並將請求通過DTO嚮應用層進行傳遞，根據應用層返回的DTO數據，再將DTO轉化爲頁面需要呈現的VO數據，進行最後的頁面展示。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當請求到達應用層後，如果需要調用外部服務的接口，那麼我們需要通過應用層的防腐層進行調用。那麼爲什麼需要防腐層進行調用而不是直接調用呢？主要的原因就是爲了隔離接口數據變化，防止外在服務的數據變化影響應用層的代碼，如果真的需要修改那麼直接在防腐層中進行修改就好了。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在領域層，我通常使用的是model，可以理解爲業務領域模型，主要包括實體以及值對象。在應用層會將model作爲參數進行領域層接口的調用完成核心的業務邏輯。在一些其他的書中，很多人喜歡使用DO來作爲領域層的數據承載對象，但是我個人還是覺得model更適合，因爲從名稱上面更好理解一點，更加直觀一點，一看就知道是模型，什麼模型，當然是業務的領域模型。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"領域層中包含了倉儲的接口，具體的實現在基礎層中，這是一種依賴倒置的設計方式，實現領域層與基礎層的解耦。其他的書中喜歡使用PO作爲這層的數據載體，我習慣使用DO。因爲DO就是數據對象，天然的和數據庫應該對應在一起，筆者同樣覺得這樣更加直觀。具體怎麼用還是看各位在實際落地使用的時候的習慣吧。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/52/520e7df828d5a8a8d228fd5173d3d32f.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"領域模型與代碼模型映射","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"工程分層","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/76/76f086d22768bd88aff6a04997294af7.png","alt":null,"title":"","style":[{"key":"width","value":"50%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如上圖所示，我們在微服務拆分後，將微服務內部的代碼層級主要分爲interfaces、biz、domain以及instructure這四層，分別對應用戶接口層、業務層、領域服務層以及基礎設施層，注意這裏的biz層實際就是application層，用爲筆者覺得application層不好理解，而biz層更好理解一點，實際他們的功能是一樣的，只是爲了減低下理解的成本。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"interfaces層：","attrs":{}},{"type":"text","text":"就是用戶接口層，這裏主要存放一些與前端交互的代碼以及與其他服務交互的接口，主要的作用將將前端請求轉化爲適當數據去調用biz層的業務代碼進行業務請求，另外將biz層返回的數據進行組裝最終形成頁面所需要的數據。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"biz層：","attrs":{}},{"type":"text","text":"其實就是application層，但是我更願意叫biz層，因爲這層的作用實際就是進行服務組合以及服務調度的，實際它是基於下層的領域服務去完成業務邏輯流程的，因此我覺得叫biz層更加貼切一點。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"domain層：","attrs":{}},{"type":"text","text":"這是整個微服務的核心層，主要包含了領域模型、領域服務以及核心的業務邏輯。領域模型主要包括了聚合中的聚合根、實體以及值對象，領域事件也會放在這一層中。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"instructure層：","attrs":{}},{"type":"text","text":"基礎設施層主要包含了各種通用能力以及工具類，它的作用就是爲上層提供基礎服務的，如數據庫服務、MQ服務以及緩存服務等還有其他的一些配置以及資源。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"代碼歸位","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"1、interfaces層","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（1）assemble 主要負責實現vo與dto之間的數據轉換工作。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（2）vo存放需要呈現在頁面的視圖數據對象。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（3）facade主要實現本層的接口封裝。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/77/770153a6187edb4b3d136332d4222b3f.png","alt":null,"title":"","style":[{"key":"width","value":"50%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"2、biz層","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"按照我自己的習慣，筆者是按照互粉的領域來進行包構建的，比如這裏的user以及authority就是不同的領域。爲什麼這麼劃分呢？主要考慮到未來萬一有新的拆分，我們可以直接按照對應的域進行拆分，效率要比在不同包中一個一個類找相關的高的多。另外按照領域劃分也比較清晰。可以方便的熟悉業務。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（1）dto中主要放了數據傳輸對象，biz層接口的入參以及返回值都是dto。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（2）service就是biz的接口以及接口實現，主要的作用就是實現對於領域服務的編排以及組合，從而完成具體的業務流程。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（3）event主要放的是事件發佈以及訂閱的相關代碼，實際具體的事件核心邏輯可以放在domain層中進行處理。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/ae/aea542af6140b1dcb90edada673398d5.png","alt":null,"title":"","style":[{"key":"width","value":"50%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"3、domain層","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"說實話，以前我們經常使用以數據驅動的設計以及開發方式，大部分的業務邏輯都是在biz層完成的，但是領域驅動設計和數據驅動設計最大的不同就是，大部分核心的業務邏輯需要下沉到domain層中。實際一開始進行這種方式的開發的時候非常的不習慣，但是當你實際沉下心來做的時候會發現，的確這種開發方式更加的能體現DDD的優勢。另外這裏還是根據領域進行劃分，和biz層是一樣的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（1）event主要放事件處理的核心邏輯代碼。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（2）model中就是具體的實體。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（3）repo主要存放持久化的代碼。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（4）service主要存放領域服務的核心業務邏輯代碼。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"（5）valueobject主要存放值對象。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/29/290e8b8ed26a520717b7a9bc7b1ecb2c.png","alt":null,"title":"","style":[{"key":"width","value":"50%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"4、instructure層","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這層的話主要存放一些基礎中間件的鏈接配置代碼以及domain的repo實現代碼以及其他一些資源類的代碼。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/49/495d42d86d5b840c0d9a219e79f012ba.png","alt":null,"title":"","style":[{"key":"width","value":"50%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"總結","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"DDD領域建模設計的理論中並沒有對在工程結構怎麼落地實際的代碼做出硬性規定，本文主要根據筆者自己的一些思考以及實踐經驗梳理了領域模型與代碼模型映射的結構，希望對大家再各自業務落地DDD實踐的時候有所參考。到這裏我們實現DDD落地的所有準備工作都差不多了，後面的文章中我們將根據真實的業務場景進行真正的落地實踐，從業務分析到領域建模，從領域分層到代碼實現。我想通過這一系列的理論加實踐的方式，相信大家可以真正領悟到DDD的魅力所在。","attrs":{}}]}]}