DDD（領域驅動設計）
（轉自：https://blog.csdn.net/bestcxx/article/details/106353819）
1. 程序員的角度
非DDD: 結構體+set/get 2者放在實體層，喫飯等天生的方法放在service層
DDD: 結構體+set/get+喫飯等天生的方法 3者都放在實體層
2. 總監的角度
我在項目需求分析的時候就設定好每個實體的基本函數並和實體定義在一起，而不是放在業務層一行一行的每個程序員去自己隨便寫
基於DDD的微服務設計
（轉自：https://www.infoq.cn/article/s_LFUlU6ZQODd030RbH9）
微服務內有 Facade 接口、應用服務、領域服務和基礎服務，各層服務協同配合，爲外部提供服務。
1、接口服務
接口服務位於用戶接口層，用於處理用戶發送的 Restful 請求和解析用戶輸入的配置文件等，並將信息傳遞給應用層。
2、應用服務
應用服務位於應用層。用來表述應用和用戶行爲，負責服務的組合、編排和轉發，負責處理業務用例的執行順序以及結果的拼裝。
應用層的服務包括應用服務和領域事件相關服務。
應用服務可對微服務內的領域服務以及微服務外的應用服務進行組合和編排，或者對基礎層如文件、緩存等數據直接操作形成應用服務，對外提供粗粒度的服務。
領域事件服務包括兩類：領域事件的發佈和訂閱。通過事件總線和消息隊列實現異步數據傳輸，實現微服務之間的解耦。
3、領域服務
領域服務位於領域層，爲完成領域中跨實體或值對象的操作轉換而封裝的服務，領域服務以與實體和值對象相同的方式參與實施過程。
領域服務對同一個實體的一個或多個方法進行組合和封裝，或對多個不同實體的操作進行組合或編排，對外暴露成領域服務。領域服務封裝了核心的業務邏輯。實體自身的行爲在實體類內部實現，向上封裝成領域服務暴露。
爲隱藏領域層的業務邏輯實現，所有領域方法和服務等均須通過領域服務對外暴露。
爲實現微服務內聚合之間的解耦，原則上禁止跨聚合的領域服務調用和跨聚合的數據相互關聯。
4、基礎服務
基礎服務位於基礎層。爲各層提供資源服務（如數據庫、緩存等），實現各層的解耦，降低外部資源變化對業務邏輯的影響。
基礎服務主要爲倉儲服務，通過依賴反轉的方式爲各層提供基礎資源服務，領域服務和應用服務調用倉儲服務接口，利用倉儲實現持久化數據對象或直接訪問基礎資源。