最近再看阮一峰的一篇博客提到了一本書《Software Architecture Patterns》（PDF）
,寫的不錯,雖然英語很屎,過年找點事干,試著翻(gu)譯(ge)一下.以下為翻譯的內容，祝我能夠翻譯完，并借此機會能夠加深對架構的認識。

Software Architecture Patterns 封面

ps:建議看英文原著。
ps:[ ]中的話是我說的。
ps:好吧,我找到已經有一個翻譯版本了(https://github.com/hehonghui/android-tech-frontier/tree/master/software-architecture-patterns)
早看到就不翻譯了......

參考:
阮一峰的博客
 鳥窩的博客

介紹

開發人員在沒有合適架構的情況下開始編寫程序是非常普遍的情況. 在這種情況下,大多數開發人員和架構師會采用傳統分層架構模式（也稱為n層架構),通過將源碼模塊分成各種包來表示抽象層。不幸的是，這種做法經常導致的是一個混亂的源碼結構，它們缺乏明確的角色，職責和彼此之間的關系。這通常被稱為反模式的大泥球。

沒有通過架構設計的應用程序通常緊密耦合，脆弱，難以改變，沒有清晰結構。如果沒有完全理解系統中的每個組件和模塊的內部工作原理的情況下，確定程序的架構特性會是非常困難的事情。關于程序部署和維護的基本問題也會很難回答：架構是否具有可擴展性？應用程序的性能如何？程序是否能夠應對變化？程序如何部署？架構的響應能力如何？

架構模式有助于定義應用程序的基本特征和行為。例如，一些架構模式非常適合需要高可擴展性的應用程序，一些架構模式則適用于非常靈活的應用程序。只有了解各種架構模式的優勢和弱點，才能夠選擇出滿足自己業務特點和目標的架構模式。

作為一個架構師，你必須證明你的架構決策，特別是當涉及到選擇一個特定的架構模式或方法。這篇文正的目的是為您提供足夠的信息，以證明你的選擇是OK的。

1.分層架構(Layered Architecture)

分層架構是最常見的架構，也是javaee應用程序的標準模式，并被多數開發人員了解。這種架構適合于傳統IT通信和組織結構，成為大多數業務應用程序開發工作的自然選擇。

模式描述(Pattern Description)

該架構中每一層都包含多個組件并且擁有具體的職責(例如顯示邏輯、業務邏輯)。該架構并不嚴格規定層的類型和層數，多數分層架構包含視圖層、業務層、持久化層和數據庫層(圖1-1)。有時，業務層和持久層被合并為單個業務層，特別是當持久性邏輯（例如，生成SQL或HSQL）嵌入到業務層組件中。因此，較小的應用可以僅具有三個層，而大的應用可以包含五個或更多個層[對于多數應用四層足以]。

圖1-1 分層架構

分層架構模式的每一層在應用程序中都有特定的角色和職責。例如，表示層將負責處理所有的用戶界面邏輯，而業務層負責響應表示層的請求并執行相應的業務邏輯。架構中的每一層都圍繞需要完成的工作形成抽象，以滿足特定的業務請求。例如，表示層不需要知道或擔心如何獲得客戶數據;它只需要在特定格式的屏幕上顯示該信息。類似地，業務層不需要關心如何格式化客戶數據以在屏幕上顯示或者甚至在客戶數據來自哪里;它只需要從持久層獲得數據，對數據執行業務邏輯（例如，計算值或聚合數據），并將該信息傳遞到表示層。

分層架構模式的一個強大的功能是組件之間的關注點分離(separation of concerns)。特定層中的組件僅處理與該層相關的邏輯。例如，表示層中的組件只處理表示邏輯，而業務層的組件只處理業務邏輯。這種組件分類方式使您可以輕松地在您的架構中構建有用的模型，并且由于定義明確的組件接口和有限的組件范圍，還可以輕松地使用此架構模式開發，測試，管理和維護應用程序。

關鍵概念(Key Concepts)

在圖1-2中，架構中的每個層都標記為封閉。這是分層架構模式中非常重要的概念。關閉意味著當請求從一個層移動到另一個層時，它必須經過它的下層，才能到達目的層。例如，一個請求從表示層要到數據庫層就必須經過業務層和持久層。

圖1-2 關閉層和請求訪問

那么為什么不允許表示層直接訪問持久層或數據庫層？畢竟，從表示層的直接數據庫訪問比通過一堆不必要的層來檢索或保存數據庫信息要快得多。這個問題的答案在于一個被稱為隔離層(layers of isolation)的關鍵概念。

隔離層意味著在一個層的變化通常不會影響到其它層的組件。如果你允許表示層直接訪問持久層，那么持久層的變化將會同時影響業務層和表示層，從而產生了非常緊密耦合和組件之間的依賴性。當需求發生變化時，這種架構將會付出較大的代價。

隔離概念的層還意味著每個層獨立于其他層，并且不需要知道其它層是如何工作的。為了理解這個概念的重要性，考慮一個大規模的重構，將展示框架從JSP（Java服務器頁面）修改為JSF（Java服務器面。假設在表示層和業務層之間使用的契約(contracts)（例如，模型）保持相同，則業務層不受重構的影響并且完全和表示層保持獨立。

雖然封閉的層有助于層次之間的隔離，從而提高了架構的低耦合設計，但有時候某些層被打開是有意義的。例如，假設您要增加一個共享服務層向業務層的組件提供服務（例如，數據和字符串實用程序類或審計和日志記錄類）。在這種情況下創建服務層通常是一個好主意，因為在體系結構上，它將對共享服務的訪問限制為業務層（而不是表示層）。沒有單獨的層，在架構上沒有限制表示層訪問這些公共服務，使得難以管理該訪問限制[這句話沒看懂，回頭再看]。

在該示例中，新服務層可能駐留在業務層之下，同時表明該服務層中的組件不能被表示層訪問。然而，這衍生出一個新的問題，業務層需要經過服務層以到達持久層，但這根本沒有意義。這是分層架構的一個古老的問題，需要通過在架構內創建開放層來解決。

如圖1-3所示，在這種情況下，服務層被標記為打開，意味著改層可以被繞過。在以下示例中，由于服務層是打開的，因此業務層現在允許繞過它，并直接轉到持久層，這是完全合理的。

圖1-3 打開層和請求流

利用開放層和封閉層的概念有助于定義層次和請求流之間的關系，并且向設計者和開發者提供理解架構內的各種層訪問限制的必要信息。如果不能確定架構中的哪些層是開放和封閉的（以及為什么）通常會導致架構難以測試，維護和部署的緊密耦合和脆弱。

架構例子(Pattern Example)

為了說明分層架構的工作原理，考慮一個來自用戶檢索客戶信息的請求，如圖1-4所示。黑色箭頭顯示請求流向數據庫以檢索客戶數據，紅色箭頭顯示響應返回到屏幕以顯示數據。在該示例中，客戶信息包括客戶數據和訂單數據（由客戶下達的訂單)。

圖1-4 分層架構例子

如圖所示，customer screen模塊負責接受用戶請求并顯示客戶信息，它不知道數據在哪里，如何檢索，也不了解數據庫，該模塊收到查詢客戶信息的請求后，將該請求轉發到customer delegate模塊，該模塊負責了解業務層中哪些模塊可以處理該請求，以及如何獲取該模塊需要的數據（例如合同數據）。業務層中的custom object負責收集(aggregating)業務請求所需的所有信息（該例子中是指客戶信息）。該模塊調用customer dao(數據訪問對象)模塊在持久層中獲取客戶數據，并且還通過order dao模塊獲取訂單信息。這些模塊又執行SQL語句來檢索相應的數據，并將其傳回給業務層中的customer object模塊。一旦customer object接收到數據，它整合數據并將該信息傳遞回customer delegate，然后將該數據傳遞到customer screen以呈現給用戶。

從技術的角度來看，這些模塊可以有很多實現方式。例如，在Java平臺中，customer screen模塊可以是(JSF) Java Server Faces screen，它和customer delegage可以作為被管理的bean組件。業務層中的customer object可以是本地Spring bean對象或遠程EJB3 bean對象。之前示例中的客戶和訂單數據可以由POJO，MyBatis XML Mapper，甚至可以是JDBC調用或Hibernate查詢返回的數據封裝。在Microsoft平臺中，customer screen可以是基于.net技術體系ASP（活動服務器頁面）模塊，客戶和訂單數據可以由為ADO（ActiveX數據對象）實現。

注意事項(Considerations)

分層架構是比較實用并且通用的模式，對于多數程序是一個良好起點，尤其是當您不確定哪種架構模式最適合您的應用程序時。當選擇這種模式時，你需要從架構的角度來考慮一下幾點。

要注意的第一件事是所謂的污水池反模式(architecture
sinkhole anti-pattern)[誰能解釋一下這是啥意思]。這個反模式是這樣的，請求流簡單的穿過幾個層，每層里面基本沒有做任何業務邏輯，或者做了很少的業務邏輯。例如，假設表示層響應來自用戶的檢索客戶數據的請求。表示層將請求傳遞給業務層，業務層簡單地將請求傳遞給持久層，然后對數據庫層進行簡單的SQL調用以檢索客戶數據。然后，數據一路返回，沒有用于聚集(aggregate)，計算或變換數據的額外處理或邏輯。

每個分層架構將具有至少一些落入反模式(architecture
sinkhole anti-pattern)的情況。這里面的關鍵是分析出屬于此類別的請求的百分比。 80-20規則通常是一個良好的做法，以確定是否正在經歷這種情況。通常將大約20％的請求作為簡單傳遞處理，80％的請求具有與請求相關聯的某些業務邏輯。但是，如果您發現此比例相反，并且大多數請求是簡單的直通處理，您可能需要考慮使一些架構層打開，需要注意的是這樣會讓層次的耦合度提高，使軟件變得不易改變。

分層體系結構模式需要注意的另一個問題是，它會使得應用程序變得monolithic[這個詞不知道怎么翻譯合適]，即使你將表示層和業務層分成單獨的可部署單元。雖然某些應用程序不在乎這些問題[規模小的程序]，但它的確會帶來部署，通用魯棒性和可靠性，性能和可擴展性等方面的一些潛在問題。

模式分析(Pattern Analysis)

以下內容包含分層架構模式的常見架構特性的評級和分析。每個特性的評級基于適用于該模式的普通場景。對于此模式與本報告中其他模式如何相關的并行比較，請參見本報告末尾的附錄A.

靈活性(Overall agility)

級別:低
分析:靈活性是針對不斷變化的環境做出快速反應的能力。雖然可以通過該模式的層次隔離特點來應對變化，但是由于monolithic性質和這種模式帶來的組件間緊耦合的特性，在該體系結構模式中進行改變仍然是繁瑣和耗時的。

可部署性(Ease of deployment)

級別:低
分析:對于由該模式實現的大型應用程序來講，部署可能會是一個問題。對組件的一個小改變可能需要重新部署整個應用程序（或應用程序的大部分），導致需要加班進行規劃，調度和執行的部署。因此，此模式不適合進行可持續部署，進一步降低了部署的總體評級。

可測試性(Testability)

級別:高
分析:因為組件都隸屬于某層，而且其他層可以被插樁或者模擬，所以該模式相對容易測試。開發人員可以通過模擬展示層中的組件中進行業務層中組件的測試，或者模擬業務層以測試某些展示層組件的功能。

性能(Performance)

級別:低
分析:雖然一些分層架構可以很好地執行，但是由于必須經歷架構的多個層以滿足業務請求，效率較低，所以該模式不適用于高性能應用。

可擴展性(Scalability)

級別:低
分析:由于這種模式的緊密耦合和monolithic特點，使用此架構模式的應用程序構建通常難以擴展。您可以通過將層拆分為單獨的物理部署或將整個應用程序復制到多個節點來擴展分層體系結構，但總體來說，粒度太分散，這使其擴展成本昂貴。

開發容易度(Ease of development)

級別:高
分析:易于開發獲得相對高的分數，主要是因為這種模式是如此眾所周知的，并且實現起來不太復雜。因為大多數公司通過分層（界面，業務，數據庫）分離技能集來開發應用程序，所以這種模式成為大多數業務應用程序開發的自然選擇。公司的溝通和組織結構之間的聯系以及開發軟件的方式被概述了所謂的 Conway’s law。

2.事件驅動架構(Event-Driven Architecture)

事件驅動架構模式是一個構建高擴展性程序的分布式異步架構模式。它還具有高度適應性，可用于小型應用和大型大型應用或者是復雜的應用。事件驅動架構由異步接收、處理事件的組件構成，這些組件是高度解耦和職責單一的。

事件驅動的架構模式由兩種拓撲(topology)方式，即mediator和broker。當你想要在事件內編排一些步驟時需要mediator拓撲[wtf這句話]，而當您想要將事件鏈接在一起而不使用中央mediator時，你需要broker拓撲。因為這兩種拓撲結構的架構特性和實現策略不同，所以了解每一種拓撲結構最適合您的特定情況是非常重要的。

Mediator拓撲(Mediator Topology)

Mediator拓撲適用于事件需要經過多個步驟處理的情況。例如，進行股票交易的一個事件可能需要您首先驗證交易，然后檢查該股票交易是否符合各種合規規則，將交易分配給經紀人，計算傭金，最后完成交易。所有這些步驟需要進行精心的安排,從而可以順序的執行.

在Mediator拓撲又四部分組成:事件隊列,事件mediator,事件通道和事件處理器.事件流從客戶端向事件隊列發送事件開始，事件隊列用于將事件傳輸到事件mediator.事件mediator接收事件后,通過向事件通道發送異步事件來執行該事件的每個處理步驟.事件處理器監聽事件通,并執行特定的業務邏輯來處理事件。圖2-1說明了事件驅動架構模式的Mediator拓撲.

圖2-1 中介拓撲

在事件驅動架構中，通常有十幾到幾百個事件隊列。該模式不指定事件隊列組件的實現; 它可以是消息隊列，web服務端點或者其他什么東西。

該模式中有兩種類型的事件：初始事件和處理事件.初始事件是由調解器接收的原始事件，而處理事件是由調解器生成并且由事件處理組件接收的事件。

事件mediator 組件負責協調初始事件中包含的步驟。對于初始事件中的每一步，事件mediator將特定的處理事件發送到事件通道，然后由事件處理器接收并處理。重要的是注意事件mediator實際上不執行處理初始事件所必需的業務邏輯; 它只知道處理初始事件所需的步驟。

事件通道被事件mediator異步地將初始事傳遞給事件處理模塊. 事件通道可以是消息隊列或消息topics，盡管消息topics和mediator拓撲通常放在一起使用的更多一些，使得處理事件可以由多個事件處理器（每個事件處理器基于接收到的處理事件執行不同的任務）來處理[我感覺這里消息隊列和消息topics是兩個并列的概念,消息topics是指的是每個事件都能被處理模塊得到,有點像pub/sub,而消息隊列指的是每個事件只能又一個處理模塊得到,有點像pipeline]。

事件處理器組件包含處理處理事件所需的業務邏輯代碼。事件處理器是在應用或系統中執行特定任務的自包含的(self-contained)，獨立的，低耦合的架構組件[就是指業務模塊]。盡管事件處理器組件的粒度可以從細粒度（例如，計算訂單上的銷售稅）到粗粒度（例如，處理保險索賠）,重要的是每個事件處理器組件應該執行單個業務任務，而不依賴于其他事件處理器完成其特定任務[業務模塊之間不應該產生相互依賴]。

事件mediator可以以多種方式實現. 作為架構師，您應該了解每個細節，以確保該模式的解決方案符合您的需求。

事件mediator的最簡單和最常見的實現是通過開源框架，例如Spring Integration，Apache Camel或Mule ESB.這些開源集成中心中的事件流通常通過Java代碼或DSL（領域專用語言）實現。對于更復雜的中介和編排，您可以使用BPEL（domain-specific language）以及BPEL引擎（如開放源代碼Apache ODE）。 BPEL是一種標準的類似XML的語言，它描述了處理初始事件所需的數據和步驟。對于需要更復雜的編排（包括涉及人員交互的步驟）的非常大的應用程序，您可以使用業務流程管理器（BPM）（如jBPM）實現事件仲裁器。

理解您的需求并選擇合適的事件mediator實現，對使用此拓撲的任何事件驅動成功至關重要。使用開源集成中心來執行非常復雜的業務流程管理編排是不正確的，就像實施一個BPM解決方案來執行簡單的路由邏輯一樣[宰牛不能用殺雞刀,殺雞不能用宰牛刀]。

為了說明mediator拓撲是如何工作的，假設你通過保險公司投保，并決定修改。在這種情況下，初始事件可能被稱為重定位事件(relocation
event)。處理重定位事件涉及的步驟包含在事件mediator中，如圖2-2所示。對于每個初始事件步驟，事件中介器創建處理事件（例如，改變地址，重新計算報價等），將該處理事件發送到事件信道，并等待由相應的事件處理器處理的處理事件（例如，客戶過程，報價過程等）。該過程繼續，直到初始事件中的所有步驟都已被處理。在Event Mediator中,Recalc Quate和Update Claims上面的箭頭代表這兩個步驟可同時進行。

圖2-2 中介模式例子

Broker拓撲架構[broker就是代理的意思]

Broker拓撲不同于mediator拓撲，因為沒有中心事件mediator,消息通過輕量級消息代理（例如，ActiveMQ，HornetQ等)[Rabbitmq,zeromq]發布給業務組件。當您具有相對簡單的事件處理流，并且您不需要中心mediator去安排更上層的業務流程，此拓撲非常有用[適合多數業務不太復雜的系統]。

該拓撲中有兩種主要類型的架構組件：代理組件和事件處理器組件。代理組件可以是一個或者好幾個(centralized or federated)，并且包含了所有的事件通道,這些通道涵蓋在事件流內。代理組件中包含的事件通道可以是消息隊列，消息主題發布或兩者的組合。

此拓撲如圖2-3所示。從圖中可以看出，沒有event-mediator組件來控制和編排初始事件; 相反，每個事件處理器組件負責處理事件并發布事件處理結果。例如，平衡股票投資組合的事件處理器可以接收稱為股票分割的初始事件。基于該初始事件，事件處理器可以進行一些組合重新平衡，然后向代理發布稱為重新平衡組合的新事件，其然后將由不同的事件處理器拾取。注意，可能存在事件由事件處理器發布但是沒有別的處理器接受的情況出現。這是常見的,尤其是當您正在開發應用程序或提供未來的功能和擴展。

圖2-3 代理拓撲

為了說明代理拓撲如何工作，我們將使用與mediator拓撲中相同的示例。由于沒有中央事件mediator來接收代理拓撲中的初始事件，客戶過程組件直接接收事件，改變客戶地址，并且發出該地址改變事件。在此示例中,有兩個對更改地址事件感興趣的事件處理器：報價過程和聲明過程。報價處理器組件根據地址更改重新計算新的自動保險率，并向系統的其余部分發布事件指示它做的事情（例如，重新計算報價事件）。另一方面，聲明處理組件接收相同的改變地址事件，但是在這種情況下，它更新未完成的保險聲明并且向系統發布事件作為更新聲明事件。這些新事件隨后被其他事件處理器組件拾取，并且事件鏈繼續通過系統，直到不再有針對該特定啟動事件發布的事件.[這不就是pr系統的設計嘛]

圖2-4 代理拓撲例子

從圖2-4中可以看出，代理拓撲結構都是關于執行業務功能的事件總線。理解代理拓撲的最好方法是將其視為中繼競賽。在接力賽中，跑步者持有接力棒并運行一定距離，然后將指揮棒交給下一個跑步者，依此類推直到最后一個運動員穿過終點線。在接力賽中，一旦運動員交出指揮棒，她就完成了比賽。這對于代理拓撲也是如此：一旦事件處理器切換事件，它不再參與該特定事件的處理。

注意事項(Considerations)

事件驅動的架構模式是一個相對復雜的模式實現，主要是由于它的異步的特點。當實現這種模式時，您必須解決各種分布式架構問題，如遠程進程可用性，缺乏響應性和代理重新連接邏輯事件代理或mediator失敗。

這種架構模式適用于缺少原子性事務的業務流程。因為事件處理器組件是高度去耦合和分布式的，所以很難跨越多個業務組件的同時去維護業務的事務特點[ACID]。因此，在使用此模式設計應用程序時，必須不斷考慮哪些事件可以獨立運行或者不單獨運行，并相應地計劃事件處理器的粒度。如果您發現由多個事件處理器構成一個工作單元，換句話說,如果您使用分散的處理器來處理不可分割的事務，在這種情況下,該模式可能不適合您的應用程序。

事件驅動的架構模式的最困難的方面之一可能是事件處理器組件之間契約(contracts)的創建，維護和管理。每個事件通常具有與它相關聯的契約形式（例如，數據值和數據格式).使用此模式來建立標準數據格式（例如，XML，JSON，Java對象等）并從一開始就建立契約的版本控制策略至關重要[業務模塊之間的接口很重要,也非常容易發生變化!!!]。