過去幾年，我們已經看到了一系列關于系統架構的想法，包括：

• 六邊形架構（接口與適配器）

• 洋蔥架構(Onion Architecture)

• Screaming Architecture

• DCI

• BCE

這些架構有很多共同的點（思想），盡管它們細節上有所不區別,它們都有相同的目標，那就是關注點分離（the speration of concerns）, 它們都是通過將軟件分層來實現這種分離，每個組件至少有一個用于業務規則的層和另一個用于接口的層。 這些架構中每一個都會產生這樣的系統：

1. 獨立的框架:該架構不依賴于某些特性軟件庫的存，

2. 可測試的（Testable）:可以在不依賴UI、數據庫、Web服務器或任何其他外部依賴的情況下進行測試

3. 獨立于UI:UI可以輕松的更改，而無需更改系統的其余部分。例如用控制臺UI(終端)代替Web UI，而不需要更改業務規則。

4. 獨立于數據庫:你可以切換底層數據庫，你的業務業務規則不應該于數據庫綁定

5. 獨立于任何外部依賴：你的業務規則根本不了解外部世界

本文頂部的圖是嘗試將所有這些體系結構集成到一個可行的想法中的嘗試。

依賴性規則(The Dependency Rule)

同心圓表示軟件的不同的領域。一般來說，隨著軟件的發展，軟件會越來越高級（可以簡單理解為分層越多）。越靠近外部的圓代表一種 機制(mechanisms)，越內部的圈代表一種政策（policy）。依賴性規則是軟件架構很重要規則，該規則定義了源碼性依賴（source code dependencies）只能指向內部，內層不需要關注任何外層的邏輯。內層的代碼不能夠引用外層的代碼，包括函數，類，變量等。

實體（Entity）

實體封裝了企業范圍的業務規則。實體可以是一個具有方法的對象，也可以是一組數據結構或函數，只要實體可以被企業多個應用程序使用，都可以成為實體。 如果你只是編寫一個簡單的業務程序（不涉及企業），那么該程序的業務對象就是實體。實體封裝了最通用和最高級的規則。當某些外部變化時，它們變化的 可能性最小。例如，你不可希望當修改一個前端頁面時，需要修改這些實體對象。對任何外層的修改都不會影響到實體層。

用例（Use Cases）

這一層通常是應用程序的業務規則（Application Specific）,它封裝并實現了應用程序的所有用例，這些用例編排流入和流出實體層的數據，通過這實體所實現 的企業業務規則實現用例業務規則。 我們不希望這一層的改變影響到實體層，同時也不會希望外層如數據庫的實現影響到這一層。

接口適配（Interface Adapters）

這一層的軟件（或模塊）是一組適配器，用來將用例層獲取的數據轉換為外層依賴（數據庫，HTTPServer）的數據格式.例如GUI的MVC結構通常在這一層實現。 實圖、演示者和控制器都屬于這一層。 同樣，這一層也會發生數據轉換，在這一層中數據會從用例層的結構裝換持久性框架的結構比如數據庫，這一層不需要關注任何數據庫實現的邏輯

框架和驅動程序（Frameworks and Drivers）

最外層通常是由框架和工具組成，如數據庫、Web框架，通常情況下這一層不需要有太多的代碼，只是一些粘合下層的代碼。這一層是所有細節所在，WEB是一個 細節，數據庫是一個細節，我們將這些放在外面，方便后續修改而不需要改動底層。

是不是只有四層？

當然不是，四層只是理想下的軟件分層模型，實際情況根據需求調整。依賴性原則始終適用，源碼依賴性始終是從外層指向內層的，越往內層移動，抽象級別越高。

跨越邊界（Crossing boundaries）

上圖的右下方是我們如何越過圓邊界的示例。它顯示了控制器和演示者在下一層與用例進行通信。注意控制流程。它從控制器開始，遍歷 用例，然后在演示者中結束執行。另請注意源代碼依賴性。他們每個人都指向用例。我們通常通過使用依賴倒置原則解決這種明顯的矛盾。 例如，在Java之類的語言中，我們將安排接口和繼承關系，以使源代碼依賴項在跨邊界的正確點處反對控制流。例如，考慮用例需要呼叫 演示者。但是，此調用不能直接進行，因為這會違反“依賴關系規則”：外層中的任何定義都不能由內層提及。 因此，我們在內層中有一個 用例調用接口（在此處顯示為用例輸出端口），并在內層中有一個演示者來實現它。使用相同的技術來跨越架構中的所有邊界。 我們利用 動態多態性來創建與控制流相反的源代碼依賴項，以便無論控制流的方向如何，我們都可以遵守“依賴關系規則”。

什么數據需要跨越邊界

通常，跨越邊界的數據是簡單的數據結構。如果愿意，可以使用基本結構或簡單的數據傳輸對象。或者，數據可以只是函數調用中的參數。 或者，您可以將其打包到一個哈希圖中，或將其構造到一個對象中。重要的是，隔離的，簡單的數據結構跨邊界傳遞。我們不想欺騙并傳 遞實體或數據庫行。我們不希望數據結構具有任何違反《依賴性規則》的依賴性。例如，許多數據庫框架都響應查詢返回方便的數據格式。 我們可以稱其為RowStructure。 我們不想將該行結構向內跨邊界傳遞。 這將違反“依賴關系規則”，因為它會迫使一個內圈知道一些 關于外圈的信息。因此，當我們跨邊界傳遞數據時，數據總是以最方便內層形式出現。

總結

遵循這些簡單規則并不難，并且可以避免許多麻煩。通過將軟件劃分為多個層，并遵循“依賴關系規則”，您將創建一個具有內在可測試性 的系統，并具有其所隱含的所有優勢。當系統的任何外部部分（例如數據庫或Web框架）過時時，您都可以以最少的麻煩替換那些過時的元素。