1. DDD 分層架構與微服務代碼模型
微服務代碼模型就是依據DDD 分層架構模型設計出來的。那爲什麼是 DDD 分層架構模型呢?
用戶接口層:面向前端提供服務適配，面向資源層提供資源適配。這一層聚集了接口適
配相關的功能。
應用層職責:實現服務組合和編排，適應業務流程快速變化的需求。這一層聚集了應用
服務和事件相關的功能。
領域層:實現領域的核心業務邏輯。這一層聚集了領域模型的聚合、聚合根、實體、值
對象、領域服務和事件等領域對象，以及它們組合所形成的業務能力。
基礎層:貫穿所有層，爲各層提供基礎資源服務。這一層聚集了各種底層資源相關的服
務和能力。
2.微服務一級目錄結構
微服務一級目錄是按照 DDD 分層架構的分層職責來定義的。從下面這張圖中，我們可以看 到，在代碼模型裏分別爲用戶接口層、應用層、領域層和基礎層，建立了 interfaces、 application、domain 和 infrastructure 四個一級代碼目錄。
這些目錄的職能和代碼形態是這樣的。
Interfaces(用戶接口層):它主要存放用戶接口層與前端交互、展現數據相關的代碼。前 端應用通過這一層的接口，嚮應用服務獲取展現所需的數據。這一層主要用來處理用戶發送 的 Restful 請求，解析用戶輸入的配置文件，並將數據傳遞給 Application 層。數據的組 裝、數據傳輸格式以及 Facade 接口等代碼都會放在這一層目錄裏。
Application(應用層):它主要存放應用層服務組合和編排相關的代碼。應用服務向下基 於微服務內的領域服務或外部微服務的應用服務完成服務的編排和組合，向上爲用戶接口層 提供各種應用數據展現支持服務。應用服務和事件等代碼會放在這一層目錄裏。
Domain(領域層):它主要存放領域層核心業務邏輯相關的代碼。領域層可以包含多個聚 合代碼包，它們共同實現領域模型的核心業務邏輯。聚合以及聚合內的實體、方法、領域服 務和事件等代碼會放在這一層目錄裏。
Infrastructure(基礎層):它主要存放基礎資源服務相關的代碼，爲其它各層提供的通用 技術能力、三方軟件包、數據庫服務、配置和基礎資源服務的代碼都會放在這一層目錄裏。
2.1 用戶接口層
Interfaces 的代碼目錄結構有:assembler、dto 和 façade 三類。
Assembler:實現 DTO 與領域對象之間的相互轉換和數據交換。一般來說 Assembler 與 DTO 總是一同出現。
Dto:它是數據傳輸的載體，內部不存在任何業務邏輯，我們可以通過 DTO 把內部的領域 對象與外界隔離。
Facade:提供較粗粒度的調用接口，將用戶請求委派給一個或多個應用服務進行處理。
2.2 應用層
Application 的代碼目錄結構有:event 和 service。
Event(事件):這層目錄主要存放事件相關的代碼。它包括兩個子目錄:publish 和 subscribe。前者主要存放事件發佈相關代碼，後者主要存放事件訂閱相關代碼(事件處理 相關的核心業務邏輯在領域層實現)。
這裏提示一下:雖然應用層和領域層都可以進行事件的發佈和處理，但爲了實現事件的統一管理，我建議你將微服務內所有事件的發佈和訂閱的處理都統一放到應用層，事件相關的核心業務邏輯實現放在領域層。通過應用層調用領域層服務，來實現完整的事件發佈和訂閱處
理流程。
Service(應用服務):這層的服務是應用服務。應用服務會對多個領域服務或外部應用服 務進行封裝、編排和組合，對外提供粗粒度的服務。應用服務主要實現服務組合和編排，是 一段獨立的業務邏輯。你可以將所有應用服務放在一個應用服務類裏，也可以把一個應用服 務設計爲一個應用服務類，以防應用服務類代碼量過大。
2.3 領域層
Domain 是由一個或多個聚合包構成，共同實現領域模型的核心業務邏輯。聚合內的代碼 模型是標準和統一的，包括:entity、event、repository 和 service 四個子目錄。
Aggregate(聚合):它是聚合軟件包的根目錄，可以根據實際項目的聚合名稱命名，比 如權限聚合。在聚合內定義聚合根、實體和值對象以及領域服務之間的關係和邊界。聚合內 實現高內聚的業務邏輯，它的代碼可以獨立拆分爲微服務。以聚合爲單位的代碼放在一個包裏的主要目的是爲了業務內聚，而更大的目的是爲了以後微服務之間聚合的重組。聚合之間清晰的代碼邊界，可以讓你輕鬆地實現以聚合爲單位的微服務重組，在微服務架構演進中有着很重要的作用。
Entity(實體):它存放聚合根、實體、值對象以及工廠模式(Factory)相關代碼。實體 類採用充血模型，同一實體相關的業務邏輯都在實體類代碼中實現。跨實體的業務邏輯代碼 在領域服務中實現。
Event(事件):它存放事件實體以及與事件活動相關的業務邏輯代碼。
Service(領域服務):它存放領域服務代碼。一個領域服務是多個實體組合出來的一段業 務邏輯。你可以將聚合內所有領域服務都放在一個領域服務類中，你也可以把每一個領域服 務設計爲一個類。如果領域服務內的業務邏輯相對複雜，我建議你將一個領域服務設計爲一 個領域服務類，避免由於所有領域服務代碼都放在一個領域服務類中，而出現代碼臃腫的問 題。領域服務封裝多個實體或方法後向上層提供應用服務調用。
Repository(倉儲):它存放所在聚合的查詢或持久化領域對象的代碼，通常包括倉儲接 口和倉儲實現方法。爲了方便聚合的拆分和組合，我們設定了一個原則:一個聚合對應一個 倉儲。
2.4 基礎層
Infrastructure 的代碼目錄結構有:config 和 util 兩個子目錄。
Config:主要存放配置相關代碼。
Util:主要存放平臺、開發框架、消息、數據庫、緩存、文件、總線、網關、第三方類庫、通用算法等基礎代碼，你可以爲不同的資源類別建立不同的子目錄。
3.代碼模型總目錄結構
