“設計原則千萬條，高内聚低耦合第一條，架構設計不規範，開發運維兩行淚！”。
整潔架構
在整潔架構裡，同心圓代表應用軟體的不同部分，從裡到外依次是領域模型、領域服務、應用服務、最外圍是容易變化的内容，如界面和基礎設施（如資料存儲等）。整潔架構是以領域模型為中心，不是以資料為中心。
依賴原則
它定義了各層的依賴關系，越往裡，依賴越低，代碼級别越高。外圓代碼依賴隻能指向内圓，内圓不知道外圓的任何事情。一般來說，外圓的聲明（包括方法、類、變量）不能被内圓引用。同樣的，外圓使用的資料格式也不能被内圓使用。
主要職能
Entities：實作領域核心心業務邏輯，它封裝了企業級的業務規則。
Use Cases：實作與使用者操作相關的服務組合與編排，它包含了應用特有的業務規則，封裝和實作了系統的所有用例。
Interface Adapters：它把适用于 Use Cases 和 entities 的資料轉換為适用于外部服務的格式，或把外部的資料格式轉換為适用于 Use Casess 和 entities 的格式。
Frameworks and Drivers：這是實作所有前端業務細節的地方：UI，Tools，Frameworks 等。
六邊形架構（又名端口擴充卡架構）
追溯微服務架構的淵源，一般會涉及到六邊形架構。六邊形架構的核心理念是：應用是通過端口與外部進行互動的，這也是微服務架構下 API 網關盛行的主要原因。六邊形架構中，内部業務邏輯（應用層和領域模型）與外部資源（APP，WEB 應用以及資料庫資源等）完全隔離，僅通過擴充卡進行互動。它解決了業務邏輯與使用者界面的代碼交錯的主要問題，進而可以很好的實作前後端分離。
主要職責
六邊形架構将系統分為内部和外部兩層六邊形，内部六邊形代表了應用的核心業務邏輯，外部六邊形代表外部應用、驅動和基礎資源等。内部通過端口和擴充卡與外部通信，對應用以 API 主動适配的方式提供服務，對資源通過依賴反轉被動适配資源的形式呈現。一個端口可能對應多個外部系統，不同的外部系統使用不同的擴充卡，擴充卡負責對協定進行轉換。這就使得應用程式能夠以一緻的方式被使用者、程式、自動化測試、批處理腳本所驅動。
CQRS（指令與查詢職責分離）
CQRS 就是讀寫分離，讀寫分離的主要目的是為了提高查詢性能，同時達到讀、寫解耦。而 DDD 和 CQRS 結合，可以分别對讀和寫模組化。
查詢模型
它是一種非規範化資料模型，它不反映領域行為，隻用于資料查詢和顯示；指令模型執行領域行為，在領域行為執行完成後通知查詢模型。
指令模型如何通知到查詢模型呢？
如果查詢模型和領域模型共享資料源，則可以省卻這一步；如果沒有共享資料源，可以借助于釋出訂閱的消息模式通知到查詢模型，進而達到資料最終一緻性。
Martin 在 blog 中指出：CQRS 适用于極少數複雜的業務領域，如果不是很适合反而會增加複雜度；另一個适用場景是為了擷取高性能的查詢服務。
對于寫少讀多的共享類通用資料服務（如主資料類應用）可以采用讀寫分離架構模式。單資料中心寫入資料，通過釋出訂閱模式将資料副本分發到多資料中心。通過查詢模型微服務，實作多資料中心資料共享和查詢。
領域驅動設計分層架構
關于分層架構的權威觀點，Martin Fowler 在《Patterns of Enterprise Application Architecture》一書中給出了答案： 1. 開發人員隻關注整個架構中的某一層。 2. 很容易的用新的方法來替換原有層次的方法。 3. 降低層與層之間的依賴。 4. 有利于标準化。 5. 利于各層邏輯的複用。
各層定義與職能
展現層：它負責向使用者顯示資訊和解釋使用者指令，完成前端界面邏輯。這裡的使用者不一定是使用使用者界面的人，也可以是另一個計算機系統。
應用層：它是很薄的一層，負責展現層與領域層之間的協調，也是與其它系統應用層進行互動的必要管道。應用層要盡量簡單，不包含業務規則或者知識，不保留業務對象的狀态，隻保留有應用任務的進度狀态，更注重流程性的東西。它隻為領域層中的領域對象協調任務，配置設定工作，使它們互相協作。
領域層：它是業務軟體的核心所在，包含了業務所涉及的領域對象（實體、值對象）、領域服務以及它們之間的關系，負責表達業務概念、業務狀态資訊以及業務規則，具體表現形式就是領域模型。領域驅動設計提倡富領域模型，即盡量将業務邏輯歸屬到領域對象上，實在無法歸屬的部分則以領域服務的形式進行定義。
基礎設施層：它向其他層提供通用的技術能力，為應用層傳遞消息（API 網關等），為領域層提供持久化機制（如資料庫資源）等。
架構模型對比和分析
雖然整潔架構、六邊形架構以及 DDD 分層架構三種架構模型展現方式以及解決問題的出發點不一樣，但其架構思想與微服務架構高内聚低耦合的設計原則高度一緻。
從上圖可以看出，在六邊形架構、DDD 分層架構的白框部分以及整潔架構 Use Cases 和 Entities 區域實作了核心業務邏輯。但是核心業務邏輯又由兩部分來完成：應用層和領域層邏輯。領域層實作了最核心的業務領域部分的邏輯，對外提供領域模型内細粒度的領域服務，應用層依賴領域層業務邏輯，通過服務組合和編排通過 API 網關向前台應用提供粗粒度的服務。
系統需求變幻無窮，但變化總是有矩可循的，使用者體驗、操作習慣、市場環境以及管理流程的變化，往往會導緻界面邏輯和流程的多變，但總體來說，不管前台如何變化，核心領域邏輯基本不會大變。把握好這個規律，我們就知道如何設計應用層和領域層，如何進行邏輯劃界了。
上述三種架構模型正是通過分層方式來控制需求變化對系統的影響，確定從外向裡受需求影響逐漸減小。面向使用者的展現層可以快速響應外部需求進行調整和釋出，靈活多變，應用層通過服務組合和編排實作業務流程的快速适配上線，領域層基本就不需要太多的變化了。這樣設計的好處是可以保證領域層的核心業務邏輯不會因為外部需求和流程的變動而調整，對于建立前台靈活、中台穩固的架構能力是很有好處的。