Robert Martin 就是我們常說的Bob大叔，是碼界的骨灰級人物了，在4年前提出了所謂的簡潔架構(gòu)，值得回顧反思一下，看看是否可以借鑒到微服務(wù)中呢?

大叔在文中介紹了一下幾種知名的架構(gòu)思想:

• Alistair Cockburn 的Hexagonal Architecture
• Jeffrey Palermo 的 Onion Architecture
• Screaming Architecture 在Bob 大叔的博客上
• DCI 是 James Coplien, 和 Trygve Reenskaug提出的架構(gòu)模型
• BCE 是 Ivar Jacobson 在其著作 Object Oriented Software Engineering: A Use-Case Driven Approach 提出的

盡管這些架構(gòu)在細(xì)節(jié)上有各種各樣的不同，大叔認(rèn)為是相似的，都有著相同的目標(biāo)就是——關(guān)注點(diǎn)分離，通過關(guān)注點(diǎn)分離把軟件分成若干層，系統(tǒng)都是這樣的:

• 獨(dú)立的框架。架構(gòu)不依賴于功能豐富的軟件庫，把框架作為工具而不是系統(tǒng)的約束。
• 可測性. 商務(wù)邏輯可以不依賴TUI, 數(shù)據(jù)庫, Web , 或其他外部元素就可以測試。
• 獨(dú)立的UI. 無需改變系統(tǒng)的其他部分就可以輕松地改變，例如 一個(gè) A Web UI 換成控制臺(tái)UI,而無需改變業(yè)務(wù)邏輯。
• 獨(dú)立的數(shù)據(jù)庫.業(yè)務(wù)邏輯不與數(shù)據(jù)庫綁定，可以在各種數(shù)據(jù)庫間切換例如 Oracle 和SQL ，Mongo與 BigTable、 CouchDB等。
• 外部代理的獨(dú)立性. 事實(shí)上，業(yè)務(wù)邏輯需要簡化到無需知道外面的世界。

因此，大叔提出的簡潔架構(gòu)試圖將這些架構(gòu)集成為一種簡單的表達(dá)形式。

這一架構(gòu)工作的***原則就是依賴原則。這一原則說明源代碼依賴指向內(nèi)部的，內(nèi)圓不知道外圓的一切， 特別地，外圓中聲明的東西不需要被內(nèi)圓中的代碼涉及，包括函數(shù)，類，變量以及其他的軟件實(shí)體。同心圓代表了軟件的不同領(lǐng)域。一般地，越深入負(fù)責(zé)，軟件的層次越多。外圓代表機(jī)制，內(nèi)圓代表策略。同樣的，外圓中的數(shù)據(jù)格式也不應(yīng)被內(nèi)圓使用，尤其是那些被外圓中的框架所生成的數(shù)據(jù)格式，并不希望外圓影響到內(nèi)圓。

實(shí)體 (Entities)

實(shí)體封裝了企業(yè)級的業(yè)務(wù)邏輯。一個(gè)實(shí)體可以是一個(gè)帶有方法的對象，或者一個(gè)數(shù)據(jù)結(jié)構(gòu)和函數(shù)的集合，實(shí)體可以被企業(yè)內(nèi)的多個(gè)應(yīng)用使用的。如果沒有企業(yè)只是寫單個(gè)應(yīng)用的話，這些實(shí)體就是應(yīng)用的業(yè)務(wù)對象。他們在外部變化時(shí)改動(dòng)最少，例如，不希望頁面導(dǎo)航的改變影響到實(shí)體對象的改變或者安全性。應(yīng)用的操作性改變不應(yīng)該影響實(shí)體層。

用例 (Use cases)

這一層的軟件包含了應(yīng)用相關(guān)的特定業(yè)務(wù)邏輯，封裝了所以的系統(tǒng)用例。這些用例編排了實(shí)體之間的數(shù)據(jù)流，目標(biāo)是將實(shí)體指向企業(yè)層面的業(yè)務(wù)規(guī)則。同樣不希望這一層影響到實(shí)體，也不希望這一層被外部元素所影響例如 數(shù)據(jù)庫， UI, 或其他通用框架。然而，希望應(yīng)用操作的改變影響這一層的用例，如果一個(gè)用例的實(shí)現(xiàn)細(xì)節(jié)改變了，這一層的一些代碼一定受到影響。

接口適配器 (Interface Adapters)

該層的軟件是一組適配器的集合，這些適配器將數(shù)據(jù)轉(zhuǎn)換成用例和實(shí)體方便使用的格式，以及一些外部代理方便使用的格式例如數(shù)據(jù)庫或者Web。例如，一個(gè)包含MVC架構(gòu)的圖形界面，Presenters, Views, 和 Controllers 都位于該層。models就像數(shù)據(jù)結(jié)構(gòu)一些從controllers傳遞到use cases,然后從用例返回到presenters 和 views。

類似的，來自實(shí)體和用例的數(shù)據(jù)會(huì)被轉(zhuǎn)換到駐留框架，例如數(shù)據(jù)庫。這一層沒有向內(nèi)的代碼來感知外部的數(shù)據(jù)庫。如果數(shù)據(jù)庫是一個(gè)SQL 數(shù)據(jù)庫的話, 那么所有SQL被限制在該層，這一層中特殊的部分處理數(shù)據(jù)庫。這一層中還有其他一些適配器轉(zhuǎn)換外部服務(wù)的數(shù)據(jù)到內(nèi)部使用的用例和實(shí)體。

框架與驅(qū)動(dòng)(Frameworks and Drivers)

最外層油框架和工具組成，如數(shù)據(jù)庫，Web框架等。 一般地，不需要寫大量的代碼就可以和內(nèi)部的圓進(jìn)行通信了。這一層細(xì)節(jié)密布，Web 是細(xì)節(jié)實(shí)現(xiàn)，數(shù)據(jù)是另一種細(xì)節(jié)，把他們保持在外可以減少傷害。

大叔的簡潔架構(gòu)只有四層么?絕對不是的，這些圓不過是示意而言，可以遠(yuǎn)多于4層的。但依賴原則總是適用的，最外圈總是底層的具體實(shí)現(xiàn)。

右下角的框圖展示了是如何跨越邊界的，描繪了Controllers 和Presenters 如何與下一層的用例通信。注意一下控制流，開始于controller, 穿過用例在presenter中執(zhí)行。這也是源代碼依賴，向內(nèi)執(zhí)行用例。這就是通常使用的DIP，在Java中，可以通過接口和繼承關(guān)系來實(shí)現(xiàn)跨邊界的控制流，動(dòng)態(tài)的多態(tài)性可以跨越這一架構(gòu)的所有邊界?？缭竭吔绲牡湫蛿?shù)據(jù)是簡單的數(shù)據(jù)結(jié)構(gòu)?？梢允褂没窘Y(jié)構(gòu)或者簡單的數(shù)據(jù)傳輸對象，或者函數(shù)的調(diào)用參數(shù)，重要的是相互隔離。例如，很多數(shù)據(jù)庫框架都在查詢時(shí)返回一個(gè)數(shù)據(jù)集， ***不要讓它跨邊界傳遞，它違反了依賴原則即內(nèi)圓知道了外圓的事情。

回顧

通過將軟件分層，遵守依賴原則，形成內(nèi)在的可測性，隔離外部的元素并具備可替代性，如此而已。

簡潔架構(gòu)更像是一種指導(dǎo)性的原則，核心同樣是關(guān)注點(diǎn)分離和分層感知，沒有擺脫企業(yè)級應(yīng)用架構(gòu)的經(jīng)典觀念。

如果聯(lián)想一下復(fù)變函數(shù)中的保角變換，這 Clean Architecture 就會(huì)變成我們熟知的有趣模樣了.......

【本文來自51CTO專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】

戳這里，看該作者更多好文