軟件架構系列二:Clean架構

     外圈的層次能夠依賴內層,反之不能夠;內圈核心的實體表明業務,不能夠依賴其所處的技術環境。html

     這是著名軟件大師Bob大叔提出的一種架構,也是當前各類語言開發架構。乾淨架構提出了一種單向依賴關係,從而在邏輯上造成一種向上的抽象系統。數據庫

     這種乾淨的架構圖以下:安全

      

     依賴規則Dependency Rule

     上圖中同心圓表明各類不一樣領域的軟件。通常來講,越深刻表明你的軟件層次越高。外圓是戰術實現機制,內圓的是戰略核心策略。服務器

     使此體系架構可以工做的關鍵是依賴規則。這條規則規定源代碼只能向內依賴,在最裏面的部分對外面一點都不知道,也就是內部不依賴外部,而外部依賴內部。這種依賴包含代碼名稱、類的函數、變量或任何其餘命名軟件實體。數據結構

     一樣,在外面圈中使用的數據格式不該被內圈中使用,特別是若是這些數據格式是由外面一圈的框架生成的。咱們不但願任何外圓的東西會影響內圈層。架構

     實體Entities

     實體封裝的是企業業務規則,一個實體能是一個帶有方法的對象,或者是一系列數據結構和函數,只要這個實體可以被不一樣的應用程序使用便可。框架

     若是你沒有編寫企業軟件,只是編寫簡單的應用程序,這些實體就是應用的業務對象。它們封裝着最普通的高級別業務規則,你不能但願這些實體對象被一個頁面的分頁導航功能改變,也不能被安全機制改變。操做實現層面的任何改變不能影響實體層,只有業務需求改變了才能夠改變實體。函數

     用例UseCases

     在這個層的軟件包含應用指定的業務規則,它封裝和實現系統的全部用例,這些用例會混合各類來自實體的各類數據流程,而且指導這些實體使用企業規則來完成用例的功能目標。工具

     咱們並不指望改變這層會影響實體層,咱們也不指望這層被更外部如數據庫、UI、普通框架影響,這層也是由於關注而外部分離的。測試

     咱們指望應用層面的技術操做都不能影響用例層,若是需求中用例發生改變,這個層的代碼纔會發生改變。

     接口適配器InterfaceAdapters

     這一層的軟件基本都是一些適配器,主要用於將用例和實體中的數據轉換爲外部系統如數據庫或Web使用的數據。在這個層次,能夠包含一些GUI的MVC架構,表現視圖與控制器都屬於這個層。模型Model是從控制器傳遞到用例或從用例傳遞到視圖的數據結構。

     一般在這個層數據被轉換,從用例和實體使用的數據格式轉換到持久層框架使用的數據,主要是爲了存儲到數據庫中。這個圈層的代碼是一點和數據庫沒有任何關係,若是數據庫是一個SQL數據庫, 這個層限制使用SQL語句以及任何和數據庫打交道的事情。

     框架和驅動

     最外面一圈一般是由一些框架和工具組成,如數據庫Database, Web框架等。一般你沒必要在這個層寫太多代碼,而是寫些膠水性質的代碼與內層進行粘結通信。這個層是細節所在,Web技術是細節,數據庫是細節,咱們將這些實現細節放在外面以避免它們對咱們的業務規則形成影響傷害。

     只有四個圈層嗎?

     這個圓圈圖是示意性的。您可能會發現您須要的不只僅是這四個。也沒有規定說你必須始終只有這四個。然而,依賴規則始終適用。源代碼的依賴關係老是由外向內。當你越向內時,抽象水平越高。而最外面的一圈是低層次的具體細節。當你越向內時軟件變得越爲抽象,封裝了更高層次的策略。

     跨邊界流程

     在圖的右下方是咱們如何越過圓邊界的例子。它顯示控制器和界面之間是如何和用例進行通訊的。注意控制流程,它開始於控制器,經過用例,而後在界面處執行。還要注意源代碼的依賴關係,它們中的每個點都是指向內部用例。咱們一般使用依賴注入來實現這種依賴。

     那麼數據如何跨層流動呢?

     一般跨層的數據是簡單的數據結構。若是你喜歡你可使用基本結構或簡單的數據傳輸對象DTO,或函數能夠調用數據參數,或者你能夠打包到哈希表中,或爲它建構一個對象。最重要是跨層傳遞是孤立的、 簡單的數據結構。

     咱們不想讓這個數據結構是一個實體或數據庫記錄,由於咱們不但願它們有任何的依賴關係,這會違反了依賴規則。例如,許多數據庫框架在查詢響應中返回一個方便的數據格式,咱們可能會要求對這個記錄重構,由於咱們不想要跨層向內傳遞數據庫記錄。這就違反了依賴規則,它會迫使內圈要知道關於外圈的東西。因此當咱們跨層傳遞數據,它老是以對內圈最方便的形式。

     總結

     符合這些簡單的規則將會節省您大量的頭痛開發。經過將軟件分離到各類層,並符合依賴規則,這樣您建立一個系統本質上是可測試的,這就意味着不少好處。

     各類軟件架構產生的系統特色是:

  1. 獨立的框架:這樣的架構並不依賴與應用軟件的具體庫包,這樣能夠將框架做爲工具,而沒必要將你的系統都胡亂混合在一塊兒;
  2. 可測試: 業務規則可以在沒有UI和數據庫 或Web服務器的狀況下被測試;
  3. UI的獨立性.:UI改變變得容易,沒必要改變系統的其他部分,一個Web UI能被一個控制檯或專門的圖形UI替代, 這些讀沒必要更改業務核心規則;
  4. 數據庫的獨立性:你可以在Oracle或SQL Server Mongo, BigTable, CouchDB,或之間切換,你的業務規則不會和數據庫綁定;
  5. 獨立的外部代理:其實你的業務規則能夠對其外面的技術世界毫無所知,好比是否使用了MVC或DCI均可以不關心;

 

轉載鏈接:http://www.jdon.com/artichect/the-clean-architecture.html

相關文章
相關標籤/搜索