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

Software Architecture Patterns 封面

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

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

介紹

開發(fā)人員在沒有合適架構(gòu)的情況下開始編寫程序是非常普遍的情況. 在這種情況下,大多數(shù)開發(fā)人員和架構(gòu)師會(huì)采用傳統(tǒng)分層架構(gòu)模式（也稱為n層架構(gòu)),通過將源碼模塊分成各種包來表示抽象層。不幸的是，這種做法經(jīng)常導(dǎo)致的是一個(gè)混亂的源碼結(jié)構(gòu)，它們?nèi)狈γ鞔_的角色，職責(zé)和彼此之間的關(guān)系。這通常被稱為反模式的大泥球。

沒有通過架構(gòu)設(shè)計(jì)的應(yīng)用程序通常緊密耦合，脆弱，難以改變，沒有清晰結(jié)構(gòu)。如果沒有完全理解系統(tǒng)中的每個(gè)組件和模塊的內(nèi)部工作原理的情況下，確定程序的架構(gòu)特性會(huì)是非常困難的事情。關(guān)于程序部署和維護(hù)的基本問題也會(huì)很難回答：架構(gòu)是否具有可擴(kuò)展性？應(yīng)用程序的性能如何？程序是否能夠應(yīng)對(duì)變化？程序如何部署？架構(gòu)的響應(yīng)能力如何？

架構(gòu)模式有助于定義應(yīng)用程序的基本特征和行為。例如，一些架構(gòu)模式非常適合需要高可擴(kuò)展性的應(yīng)用程序，一些架構(gòu)模式則適用于非常靈活的應(yīng)用程序。只有了解各種架構(gòu)模式的優(yōu)勢(shì)和弱點(diǎn)，才能夠選擇出滿足自己業(yè)務(wù)特點(diǎn)和目標(biāo)的架構(gòu)模式。

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

1.分層架構(gòu)(Layered Architecture)

分層架構(gòu)是最常見的架構(gòu)，也是javaee應(yīng)用程序的標(biāo)準(zhǔn)模式，并被多數(shù)開發(fā)人員了解。這種架構(gòu)適合于傳統(tǒng)IT通信和組織結(jié)構(gòu)，成為大多數(shù)業(yè)務(wù)應(yīng)用程序開發(fā)工作的自然選擇。

模式描述(Pattern Description)

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

圖1-1 分層架構(gòu)

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

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

關(guān)鍵概念(Key Concepts)

在圖1-2中，架構(gòu)中的每個(gè)層都標(biāo)記為封閉。這是分層架構(gòu)模式中非常重要的概念。關(guān)閉意味著當(dāng)請(qǐng)求從一個(gè)層移動(dòng)到另一個(gè)層時(shí)，它必須經(jīng)過它的下層，才能到達(dá)目的層。例如，一個(gè)請(qǐng)求從表示層要到數(shù)據(jù)庫層就必須經(jīng)過業(yè)務(wù)層和持久層。

圖1-2 關(guān)閉層和請(qǐng)求訪問

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

隔離層意味著在一個(gè)層的變化通常不會(huì)影響到其它層的組件。如果你允許表示層直接訪問持久層，那么持久層的變化將會(huì)同時(shí)影響業(yè)務(wù)層和表示層，從而產(chǎn)生了非常緊密耦合和組件之間的依賴性。當(dāng)需求發(fā)生變化時(shí)，這種架構(gòu)將會(huì)付出較大的代價(jià)。

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

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

在該示例中，新服務(wù)層可能駐留在業(yè)務(wù)層之下，同時(shí)表明該服務(wù)層中的組件不能被表示層訪問。然而，這衍生出一個(gè)新的問題，業(yè)務(wù)層需要經(jīng)過服務(wù)層以到達(dá)持久層，但這根本沒有意義。這是分層架構(gòu)的一個(gè)古老的問題，需要通過在架構(gòu)內(nèi)創(chuàng)建開放層來解決。

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

圖1-3 打開層和請(qǐng)求流

利用開放層和封閉層的概念有助于定義層次和請(qǐng)求流之間的關(guān)系，并且向設(shè)計(jì)者和開發(fā)者提供理解架構(gòu)內(nèi)的各種層訪問限制的必要信息。如果不能確定架構(gòu)中的哪些層是開放和封閉的（以及為什么）通常會(huì)導(dǎo)致架構(gòu)難以測(cè)試，維護(hù)和部署的緊密耦合和脆弱。

架構(gòu)例子(Pattern Example)

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

圖1-4 分層架構(gòu)例子

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

從技術(shù)的角度來看，這些模塊可以有很多實(shí)現(xiàn)方式。例如，在Java平臺(tái)中，customer screen模塊可以是(JSF) Java Server Faces screen，它和customer delegage可以作為被管理的bean組件。業(yè)務(wù)層中的customer object可以是本地Spring bean對(duì)象或遠(yuǎn)程EJB3 bean對(duì)象。之前示例中的客戶和訂單數(shù)據(jù)可以由POJO，MyBatis XML Mapper，甚至可以是JDBC調(diào)用或Hibernate查詢返回的數(shù)據(jù)封裝。在Microsoft平臺(tái)中，customer screen可以是基于.net技術(shù)體系A(chǔ)SP（活動(dòng)服務(wù)器頁面）模塊，客戶和訂單數(shù)據(jù)可以由為ADO（ActiveX數(shù)據(jù)對(duì)象）實(shí)現(xiàn)。

注意事項(xiàng)(Considerations)

分層架構(gòu)是比較實(shí)用并且通用的模式，對(duì)于多數(shù)程序是一個(gè)良好起點(diǎn)，尤其是當(dāng)您不確定哪種架構(gòu)模式最適合您的應(yīng)用程序時(shí)。當(dāng)選擇這種模式時(shí)，你需要從架構(gòu)的角度來考慮一下幾點(diǎn)。

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

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

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

模式分析(Pattern Analysis)

以下內(nèi)容包含分層架構(gòu)模式的常見架構(gòu)特性的評(píng)級(jí)和分析。每個(gè)特性的評(píng)級(jí)基于適用于該模式的普通場(chǎng)景。對(duì)于此模式與本報(bào)告中其他模式如何相關(guān)的并行比較，請(qǐng)參見本報(bào)告末尾的附錄A.

靈活性(Overall agility)

級(jí)別:低
分析:靈活性是針對(duì)不斷變化的環(huán)境做出快速反應(yīng)的能力。雖然可以通過該模式的層次隔離特點(diǎn)來應(yīng)對(duì)變化，但是由于monolithic性質(zhì)和這種模式帶來的組件間緊耦合的特性，在該體系結(jié)構(gòu)模式中進(jìn)行改變?nèi)匀皇欠爆嵑秃臅r(shí)的。

可部署性(Ease of deployment)

級(jí)別:低
分析:對(duì)于由該模式實(shí)現(xiàn)的大型應(yīng)用程序來講，部署可能會(huì)是一個(gè)問題。對(duì)組件的一個(gè)小改變可能需要重新部署整個(gè)應(yīng)用程序（或應(yīng)用程序的大部分），導(dǎo)致需要加班進(jìn)行規(guī)劃，調(diào)度和執(zhí)行的部署。因此，此模式不適合進(jìn)行可持續(xù)部署，進(jìn)一步降低了部署的總體評(píng)級(jí)。

可測(cè)試性(Testability)

級(jí)別:高
分析:因?yàn)榻M件都隸屬于某層，而且其他層可以被插樁或者模擬，所以該模式相對(duì)容易測(cè)試。開發(fā)人員可以通過模擬展示層中的組件中進(jìn)行業(yè)務(wù)層中組件的測(cè)試，或者模擬業(yè)務(wù)層以測(cè)試某些展示層組件的功能。

性能(Performance)

級(jí)別:低
分析:雖然一些分層架構(gòu)可以很好地執(zhí)行，但是由于必須經(jīng)歷架構(gòu)的多個(gè)層以滿足業(yè)務(wù)請(qǐng)求，效率較低，所以該模式不適用于高性能應(yīng)用。

可擴(kuò)展性(Scalability)

級(jí)別:低
分析:由于這種模式的緊密耦合和monolithic特點(diǎn)，使用此架構(gòu)模式的應(yīng)用程序構(gòu)建通常難以擴(kuò)展。您可以通過將層拆分為單獨(dú)的物理部署或?qū)⒄麄€(gè)應(yīng)用程序復(fù)制到多個(gè)節(jié)點(diǎn)來擴(kuò)展分層體系結(jié)構(gòu)，但總體來說，粒度太分散，這使其擴(kuò)展成本昂貴。

開發(fā)容易度(Ease of development)

級(jí)別:高
分析:易于開發(fā)獲得相對(duì)高的分?jǐn)?shù)，主要是因?yàn)檫@種模式是如此眾所周知的，并且實(shí)現(xiàn)起來不太復(fù)雜。因?yàn)榇蠖鄶?shù)公司通過分層（界面，業(yè)務(wù)，數(shù)據(jù)庫）分離技能集來開發(fā)應(yīng)用程序，所以這種模式成為大多數(shù)業(yè)務(wù)應(yīng)用程序開發(fā)的自然選擇。公司的溝通和組織結(jié)構(gòu)之間的聯(lián)系以及開發(fā)軟件的方式被概述了所謂的 Conway’s law。

2.事件驅(qū)動(dòng)架構(gòu)(Event-Driven Architecture)

事件驅(qū)動(dòng)架構(gòu)模式是一個(gè)構(gòu)建高擴(kuò)展性程序的分布式異步架構(gòu)模式。它還具有高度適應(yīng)性，可用于小型應(yīng)用和大型大型應(yīng)用或者是復(fù)雜的應(yīng)用。事件驅(qū)動(dòng)架構(gòu)由異步接收、處理事件的組件構(gòu)成，這些組件是高度解耦和職責(zé)單一的。

事件驅(qū)動(dòng)的架構(gòu)模式由兩種拓?fù)?topology)方式，即mediator和broker。當(dāng)你想要在事件內(nèi)編排一些步驟時(shí)需要mediator拓?fù)鋄wtf這句話]，而當(dāng)您想要將事件鏈接在一起而不使用中央mediator時(shí)，你需要broker拓?fù)?。因?yàn)檫@兩種拓?fù)浣Y(jié)構(gòu)的架構(gòu)特性和實(shí)現(xiàn)策略不同，所以了解每一種拓?fù)浣Y(jié)構(gòu)最適合您的特定情況是非常重要的。

Mediator拓?fù)?Mediator Topology)

Mediator拓?fù)溥m用于事件需要經(jīng)過多個(gè)步驟處理的情況。例如，進(jìn)行股票交易的一個(gè)事件可能需要您首先驗(yàn)證交易，然后檢查該股票交易是否符合各種合規(guī)規(guī)則，將交易分配給經(jīng)紀(jì)人，計(jì)算傭金，最后完成交易。所有這些步驟需要進(jìn)行精心的安排,從而可以順序的執(zhí)行.

在Mediator拓?fù)溆炙牟糠纸M成:事件隊(duì)列,事件mediator,事件通道和事件處理器.事件流從客戶端向事件隊(duì)列發(fā)送事件開始，事件隊(duì)列用于將事件傳輸?shù)绞录ediator.事件mediator接收事件后,通過向事件通道發(fā)送異步事件來執(zhí)行該事件的每個(gè)處理步驟.事件處理器監(jiān)聽事件通,并執(zhí)行特定的業(yè)務(wù)邏輯來處理事件。圖2-1說明了事件驅(qū)動(dòng)架構(gòu)模式的Mediator拓?fù)?

圖2-1 中介拓?fù)?/div>

在事件驅(qū)動(dòng)架構(gòu)中，通常有十幾到幾百個(gè)事件隊(duì)列。該模式不指定事件隊(duì)列組件的實(shí)現(xiàn); 它可以是消息隊(duì)列，web服務(wù)端點(diǎn)或者其他什么東西。

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

事件mediator 組件負(fù)責(zé)協(xié)調(diào)初始事件中包含的步驟。對(duì)于初始事件中的每一步，事件mediator將特定的處理事件發(fā)送到事件通道，然后由事件處理器接收并處理。重要的是注意事件mediator實(shí)際上不執(zhí)行處理初始事件所必需的業(yè)務(wù)邏輯; 它只知道處理初始事件所需的步驟。

事件通道被事件mediator異步地將初始事傳遞給事件處理模塊. 事件通道可以是消息隊(duì)列或消息topics，盡管消息topics和mediator拓?fù)渫ǔ７旁谝黄鹗褂玫母嘁恍沟锰幚硎录梢杂啥鄠€(gè)事件處理器（每個(gè)事件處理器基于接收到的處理事件執(zhí)行不同的任務(wù)）來處理[我感覺這里消息隊(duì)列和消息topics是兩個(gè)并列的概念,消息topics是指的是每個(gè)事件都能被處理模塊得到,有點(diǎn)像pub/sub,而消息隊(duì)列指的是每個(gè)事件只能又一個(gè)處理模塊得到,有點(diǎn)像pipeline]。

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

事件mediator可以以多種方式實(shí)現(xiàn). 作為架構(gòu)師，您應(yīng)該了解每個(gè)細(xì)節(jié)，以確保該模式的解決方案符合您的需求。

事件mediator的最簡(jiǎn)單和最常見的實(shí)現(xiàn)是通過開源框架，例如Spring Integration，Apache Camel或Mule ESB.這些開源集成中心中的事件流通常通過Java代碼或DSL（領(lǐng)域?qū)Ｓ谜Z言）實(shí)現(xiàn)。對(duì)于更復(fù)雜的中介和編排，您可以使用BPEL（domain-specific language）以及BPEL引擎（如開放源代碼Apache ODE）。 BPEL是一種標(biāo)準(zhǔn)的類似XML的語言，它描述了處理初始事件所需的數(shù)據(jù)和步驟。對(duì)于需要更復(fù)雜的編排（包括涉及人員交互的步驟）的非常大的應(yīng)用程序，您可以使用業(yè)務(wù)流程管理器（BPM）（如jBPM）實(shí)現(xiàn)事件仲裁器。

理解您的需求并選擇合適的事件mediator實(shí)現(xiàn)，對(duì)使用此拓?fù)涞娜魏问录?qū)動(dòng)成功至關(guān)重要。使用開源集成中心來執(zhí)行非常復(fù)雜的業(yè)務(wù)流程管理編排是不正確的，就像實(shí)施一個(gè)BPM解決方案來執(zhí)行簡(jiǎn)單的路由邏輯一樣[宰牛不能用殺雞刀,殺雞不能用宰牛刀]。

為了說明mediator拓?fù)涫侨绾喂ぷ鞯?，假設(shè)你通過保險(xiǎn)公司投保，并決定修改。在這種情況下，初始事件可能被稱為重定位事件(relocation
event)。處理重定位事件涉及的步驟包含在事件mediator中，如圖2-2所示。對(duì)于每個(gè)初始事件步驟，事件中介器創(chuàng)建處理事件（例如，改變地址，重新計(jì)算報(bào)價(jià)等），將該處理事件發(fā)送到事件信道，并等待由相應(yīng)的事件處理器處理的處理事件（例如，客戶過程，報(bào)價(jià)過程等）。該過程繼續(xù)，直到初始事件中的所有步驟都已被處理。在Event Mediator中,Recalc Quate和Update Claims上面的箭頭代表這兩個(gè)步驟可同時(shí)進(jìn)行。

圖2-2 中介模式例子

Broker拓?fù)浼軜?gòu)[broker就是代理的意思]

Broker拓?fù)洳煌趍ediator拓?fù)?，因?yàn)闆]有中心事件mediator,消息通過輕量級(jí)消息代理（例如，ActiveMQ，HornetQ等)[Rabbitmq,zeromq]發(fā)布給業(yè)務(wù)組件。當(dāng)您具有相對(duì)簡(jiǎn)單的事件處理流，并且您不需要中心mediator去安排更上層的業(yè)務(wù)流程，此拓?fù)浞浅Ｓ杏肹適合多數(shù)業(yè)務(wù)不太復(fù)雜的系統(tǒng)]。

該拓?fù)渲杏袃煞N主要類型的架構(gòu)組件：代理組件和事件處理器組件。代理組件可以是一個(gè)或者好幾個(gè)(centralized or federated)，并且包含了所有的事件通道,這些通道涵蓋在事件流內(nèi)。代理組件中包含的事件通道可以是消息隊(duì)列，消息主題發(fā)布或兩者的組合。

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

圖2-3 代理拓?fù)?/div>

為了說明代理拓?fù)淙绾喂ぷ?，我們將使用與mediator拓?fù)渲邢嗤氖纠?。由于沒有中央事件mediator來接收代理拓?fù)渲械某跏际录蛻暨^程組件直接接收事件，改變客戶地址，并且發(fā)出該地址改變事件。在此示例中,有兩個(gè)對(duì)更改地址事件感興趣的事件處理器：報(bào)價(jià)過程和聲明過程。報(bào)價(jià)處理器組件根據(jù)地址更改重新計(jì)算新的自動(dòng)保險(xiǎn)率，并向系統(tǒng)的其余部分發(fā)布事件指示它做的事情（例如，重新計(jì)算報(bào)價(jià)事件）。另一方面，聲明處理組件接收相同的改變地址事件，但是在這種情況下，它更新未完成的保險(xiǎn)聲明并且向系統(tǒng)發(fā)布事件作為更新聲明事件。這些新事件隨后被其他事件處理器組件拾取，并且事件鏈繼續(xù)通過系統(tǒng)，直到不再有針對(duì)該特定啟動(dòng)事件發(fā)布的事件.[這不就是pr系統(tǒng)的設(shè)計(jì)嘛]

圖2-4 代理拓?fù)淅?/div>

從圖2-4中可以看出，代理拓?fù)浣Y(jié)構(gòu)都是關(guān)于執(zhí)行業(yè)務(wù)功能的事件總線。理解代理拓?fù)涞淖詈梅椒ㄊ菍⑵湟暈橹欣^競(jìng)賽。在接力賽中，跑步者持有接力棒并運(yùn)行一定距離，然后將指揮棒交給下一個(gè)跑步者，依此類推直到最后一個(gè)運(yùn)動(dòng)員穿過終點(diǎn)線。在接力賽中，一旦運(yùn)動(dòng)員交出指揮棒，她就完成了比賽。這對(duì)于代理拓?fù)湟彩侨绱耍阂坏┦录幚砥髑袚Q事件，它不再參與該特定事件的處理。

注意事項(xiàng)(Considerations)

事件驅(qū)動(dòng)的架構(gòu)模式是一個(gè)相對(duì)復(fù)雜的模式實(shí)現(xiàn)，主要是由于它的異步的特點(diǎn)。當(dāng)實(shí)現(xiàn)這種模式時(shí)，您必須解決各種分布式架構(gòu)問題，如遠(yuǎn)程進(jìn)程可用性，缺乏響應(yīng)性和代理重新連接邏輯事件代理或mediator失敗。

這種架構(gòu)模式適用于缺少原子性事務(wù)的業(yè)務(wù)流程。因?yàn)槭录幚砥鹘M件是高度去耦合和分布式的，所以很難跨越多個(gè)業(yè)務(wù)組件的同時(shí)去維護(hù)業(yè)務(wù)的事務(wù)特點(diǎn)[ACID]。因此，在使用此模式設(shè)計(jì)應(yīng)用程序時(shí)，必須不斷考慮哪些事件可以獨(dú)立運(yùn)行或者不單獨(dú)運(yùn)行，并相應(yīng)地計(jì)劃事件處理器的粒度。如果您發(fā)現(xiàn)由多個(gè)事件處理器構(gòu)成一個(gè)工作單元，換句話說,如果您使用分散的處理器來處理不可分割的事務(wù)，在這種情況下,該模式可能不適合您的應(yīng)用程序。

事件驅(qū)動(dòng)的架構(gòu)模式的最困難的方面之一可能是事件處理器組件之間契約(contracts)的創(chuàng)建，維護(hù)和管理。每個(gè)事件通常具有與它相關(guān)聯(lián)的契約形式（例如，數(shù)據(jù)值和數(shù)據(jù)格式).使用此模式來建立標(biāo)準(zhǔn)數(shù)據(jù)格式（例如，XML，JSON，Java對(duì)象等）并從一開始就建立契約的版本控制策略至關(guān)重要[業(yè)務(wù)模塊之間的接口很重要,也非常容易發(fā)生變化!!!]。

模式分析(Pattern Analysis)

該章節(jié)包含事件驅(qū)動(dòng)架構(gòu)模式的常見架構(gòu)特性的評(píng)級(jí)和分析。每個(gè)特性的評(píng)級(jí)基于自然趨勢(shì)或該特性作為基于圖案的典型實(shí)施的能力，以及通常已知的圖案。對(duì)于此模式與本報(bào)告中其他模式如何相關(guān)的并行比較，請(qǐng)參見本報(bào)告末尾的附錄A.