又稱乾淨的架構The Clean Architecture，這是著名軟件工程大師Robert C Martin提出的一種架構整潔清晰之道，也是當前各種語言開發的目標架構。乾淨、清晰、整潔的架構應該只包含單向的依賴關係，這樣纔可以在邏輯上形成一種向上的抽象系統。
我們經常聽說過如下各種架構：
六邊形架構Hexagonal Architecture (也稱爲 端口和適配器) 這是由Alistair Cockburn 提出，被Steve Freeman和 Nat Pryce在他們的書籍Growing Object Oriented Software中採取的。
Onion Architecture 作者Jeffrey Palermo
Screaming Architecture Bob大叔
DCI 由James Coplien和Trygve Reenskaug推動
BCE Ivar Jacobson在他的書籍Object Oriented Software Engineering: A Use-Case Driven Approach提出
雖然這些架構在細節上都略有不同，但他們都非常相似。它們都具有相同的目標，那就是分離關注。他們都通過軟件分層來實現這種分離。至少有一個層代表業務規則，而另一個層用於接口。
這些架構產生的系統特點是：
獨立的框架. 這樣的架構並不依賴與應用軟件的具體庫包，這樣可以將框架作爲工具，而不必將你的系統都胡亂混合在一起。
可測試. 業務規則能夠在沒有UI和數據庫 或Web服務器的情況下被測試。
UI的獨立性. UI改變變得容易，不必改變系統的其餘部分，一個Web UI能被一個控制檯或專門的圖形UI替代, 這些讀不必更改業務核心規則。
數據庫的獨立性. 你能夠在Oracle或SQL Server Mongo, BigTable, CouchDB,或之間切換, . 你的業務規則不會和數據庫綁定
獨立的外部代理，其實你的業務規則可以對其外面的技術世界毫無所知，比如是否使用了MVC或DCI都可以不關心。
這種乾淨的架構圖如下：
依賴規則Dependency Rule
上圖中同心圓代表各種不同領域的軟件。一般來說，越深入代表你的軟件層次越高。外圓是戰術實現機制，內圓的是戰略核心策略。
使此體系架構能夠工作的關鍵是依賴規則。這條規則規定源代碼只能向內依賴，在最裏面的部分對外面一點都不知道，也就是內部不依賴外部，而外部依賴內部。這種依賴包含代碼名稱，或類的函數，變量或任何其他命名軟件實體。
同樣，在外面圈中使用的數據格式不應被內圈中使用，特別是如果這些數據格式是由外面一圈的框架生成的。我們不希望任何外圓的東西會影響內圈層。
實體Entities
實體封裝的是企業業務規則，一個實體能是一個帶有方法的對象，或者是一系列數據結構和函數，只要這個實體能夠被不同的應用程序使用即可。
如果你沒有編寫企業軟件，只是編寫簡單的應用程序，這些實體就是應用的業務對象，它們封裝着最普通的高級別業務規則，你不能希望這些實體對象被一個頁面的分頁導航功能改變，也不能被安全機制改變，操作實現層面的任何改變不能影響實體層，只有業務需求改變了纔可以改變實體。
用例Use Cases
在這個層的軟件包含應用指定的業務規則，它封裝和實現系統的所有用例，這些用例會混合各種來自實體的各種數據流程，並且指導這些實體使用企業規則來完成用例的功能目標。
我們並不期望改變這層會影響實體層. 我們也不期望這層被更外部如數據庫 UI或普通框架影響，這層也是因爲關注而外部分離的。
我們期望應用層面的技術操作都不能影響用例層，如果需求中用例發生改變，這個層的代碼纔會發生改變。
接口適配器Interface Adapters
這一層的軟件基本都是一些適配器，主要用於將用例和實體中的數據轉換爲外部系統如數據庫或Web使用的數據，在這個層次，可以包含一些GUI的MVC架構，表現視圖 控制器都屬於這個層，模型Model是從控制器傳遞到用例或從用例傳遞到視圖的數據結構。
通常在這個層數據被轉換，從用例和實體使用的數據格式轉換到持久層框架使用的數據，主要是爲了存儲到數據庫中，這個圈層的代碼是一點和數據庫沒有任何關係，如果數據庫是一個SQL數據庫， 這個層限制使用SQL語句以及任何和數據庫打交道的事情。
框架和驅動
最外面一圈通常是由一些框架和工具組成，如數據庫Database, Web框架等. 通常你不必在這個層不必寫太多代碼，而是寫些膠水性質的代碼與內層進行粘結通訊。這個層是細節所在，Web技術是細節，數據庫是細節，我們將這些實現細節放在外面以免它們對我們的業務規則造成影響傷害。
只有四個圈層嗎？
這個圓圈圖是示意性的。您可能會發現您需要的不僅僅是這四個。也沒有規定說你必須始終只有這四個。然而，依賴規則始終適用。源代碼的依賴關係總是由外向內。當你越向內時，抽象水平越高。而最外面的一圈是低層次的具體細節。當你越向內時軟件變得越爲抽象，封裝了更高層次的策略。
跨邊界流程
在圖的右下方是我們如何越過圓邊界的例子。它顯示控制器和界面之間是如何和用例進行通信的。注意控制流程。它開始於控制器，通過用例，然後在界面處執行。還要注意源代碼的依賴關係。他們中的每一個點都是指向內部用例。我們通常使用依賴注入來實現這種依賴。
那麼數據如何跨層流動呢？
通常跨層的數據是簡單的數據結構。如果你喜歡你可以使用基本結構或簡單的數據傳輸對象DTO。或可以函數可以調用數據參數。或者你可以打包到哈希表中，或爲它建構一個對象。最重要是跨層傳遞是孤立的、 簡單的數據結構。
我們不想讓這個數據結構是一個實體或數據庫記錄，因爲我們不希望它們有任何的依賴關係，這會違反了依賴規則。例如，許多數據庫框架在查詢響應中返回一個方便的數據格式。我們可能會要求這對這個記錄重構，因爲我們不想要跨層向內傳遞數據庫記錄。這就違反了依賴規則，它會迫使內圈要知道關於外圈的東西。所以當我們跨層傳遞數據，它總是以對內圈最方便的形式。
總結
符合這些簡單的規則將會節省您大量的頭痛開發。通過將軟件分離到各種層，並符合依賴規則，這樣您創建一個系統本質上是可測試，這意味着很多好處。
關於這本書歸納也可以參考下面兩篇文章：
http://hongchaozhang.github.io/blog/2019/02/12/reading-the-clean-architecture/
https://blog.csdn.net/b0Q8cpra539haFS7/article/details/90205021