在Brooks的最新力作《設(shè)計(jì)原本(The Design of Design)》一書(shū)中，提及“一致性”對(duì)軟件的重要性。他認(rèn)為：“一致性應(yīng)該是所有質(zhì)量原則的根基。好的架構(gòu)應(yīng)該是直接的，人們掌握了部分系統(tǒng)后就可以推測(cè)出其他部分”。這種所謂“窺一斑而知全豹”的要求，實(shí)則是要求保持風(fēng)格的一致性。

　　風(fēng)格的一致性

　　許多軟件公司都會(huì)根據(jù)自身情況并結(jié)合業(yè)界規(guī)范制定符合本公司情況的編碼規(guī)范。例如對(duì)命名、格式等諸多風(fēng)格的要求。這種編碼風(fēng)格的一致性是相對(duì)容易實(shí)現(xiàn)的。Brooks提到的一致性，更多地是體現(xiàn)架構(gòu)風(fēng)格的一致性。那么，什么是架構(gòu)風(fēng)格（Architecture Style)？在微軟撰寫(xiě)的Application Architecture Guide 2.0一書(shū)中，將架構(gòu)風(fēng)格定義為一組原則的集合，是為系統(tǒng)家族提供抽象框架的粗粒度模式。架構(gòu)風(fēng)格可以改善設(shè)計(jì)，促進(jìn)重用，為常見(jiàn)的問(wèn)題提供可靠的解決方案。而Mary Shaw對(duì)架構(gòu)風(fēng)格的定義則顯得更加晦澀一些：“架構(gòu)風(fēng)格根據(jù)結(jié)構(gòu)組織的模式定義系統(tǒng)種類(lèi)。更具體地說(shuō)，架構(gòu)風(fēng)格定義組件和連接器類(lèi)型的詞匯及它們?nèi)绾芜M(jìn)行組合的一組約束。”顯然，Mary Shaw認(rèn)為架構(gòu)風(fēng)格定義了架構(gòu)組成元素的結(jié)構(gòu)以及它們必須遵循的一些原則和約束。

　　架構(gòu)風(fēng)格可能是對(duì)一些架構(gòu)模式的運(yùn)用，然而在運(yùn)用模式之前，首先需要分辨系統(tǒng)的類(lèi)別。例如系統(tǒng)如果是業(yè)務(wù)復(fù)雜的企業(yè)應(yīng)用，那么就領(lǐng)域?qū)佣裕蛻?yīng)該選擇領(lǐng)域模型（Domain Model），通過(guò)有效地利用對(duì)象、組件和服務(wù)保證系統(tǒng)的可重用性與可擴(kuò)展性。而一旦選擇了領(lǐng)域模型，那么在通常情況下，就不應(yīng)該在同一個(gè)系統(tǒng)的其他模塊中采用事務(wù)腳本（Transaction Script）模式。否則，我們就違背了風(fēng)格的一致性。

　　我們常常會(huì)將選定的架構(gòu)風(fēng)格作為整個(gè)系統(tǒng)架構(gòu)的核心框架。了解了架構(gòu)風(fēng)格，就可以有助于了解整個(gè)軟件系統(tǒng)。例如，對(duì)于數(shù)據(jù)分析器系統(tǒng)而言，它的核心邏輯是輸入數(shù)據(jù)流、輸出數(shù)據(jù)流與分析算法之間的協(xié)作。由于分析算法是對(duì)數(shù)據(jù)流的一種篩選和過(guò)濾，我們選定的架構(gòu)風(fēng)格是采用管道-過(guò)濾器（Pipes and Filters）模式。那么，在了解數(shù)據(jù)分析器的架構(gòu)時(shí)，只要掌握了管道-過(guò)濾器模式的核心思想，就能夠快速把握系統(tǒng)架構(gòu)的核心。這有利于系統(tǒng)知識(shí)的延續(xù)，并保證整個(gè)系統(tǒng)的一致性。

　　當(dāng)然，架構(gòu)風(fēng)格的選擇會(huì)因?yàn)殛P(guān)注點(diǎn)的不同，產(chǎn)生不同的解決方案。例如，從部署的角度來(lái)看，我們可能需要選擇分布式部署的物理架構(gòu)；而對(duì)于同一個(gè)系統(tǒng)而言，由于需要考慮消息的傳遞，我們又可能選擇消息總線(xiàn)的方式。這與風(fēng)格的一致性并不矛盾。我們只需保證在同一個(gè)關(guān)注面上，保持一致的風(fēng)格即可。

　　解決方案的一致性

　　風(fēng)格的一致性屬于軟件架構(gòu)的層面，與之相似的是保證解決方案的一致性。在整個(gè)系統(tǒng)架構(gòu)中，解決方案必須是一致的，否則就可能導(dǎo)致混亂的架構(gòu)與代碼。那么，怎樣才能保證解決方案的一致性呢？首要條件是在進(jìn)行系統(tǒng)架構(gòu)之前，我們必須根據(jù)系統(tǒng)與團(tuán)隊(duì)的情況，制定被團(tuán)隊(duì)成員廣泛接受的架構(gòu)原則。例如，我們可以為系統(tǒng)制訂分層指導(dǎo)原則。對(duì)于領(lǐng)域?qū)樱覀冏裱璂DD的要求，為領(lǐng)域模型確定實(shí)體、值對(duì)象、聚合根、服務(wù)、工廠(chǎng)與資源庫(kù)之間的明確劃分，并明確地指出它們應(yīng)該具備的特征。我們要求應(yīng)用服務(wù)層不應(yīng)包含任何業(yè)務(wù)邏輯，只負(fù)責(zé)UI與領(lǐng)域?qū)又g的消息傳遞，并可調(diào)用基礎(chǔ)設(shè)施中公共模塊的數(shù)據(jù)驗(yàn)證、緩存和安全等功能。我們要求應(yīng)用服務(wù)層不應(yīng)保留業(yè)務(wù)對(duì)象的狀態(tài)，僅僅負(fù)責(zé)協(xié)調(diào)應(yīng)用的活動(dòng)，并要求所有公開(kāi)在外的應(yīng)用服務(wù)均定義為接口。

　　在制訂了這樣的架構(gòu)原則后，我們就可以統(tǒng)一系統(tǒng)的解決方案。例如遵循之前的分層指導(dǎo)原則，我們可以獲得如下的針對(duì)領(lǐng)域?qū)拥慕y(tǒng)一解決方案：

　　如果我們沒(méi)有保證解決方案的一致性，并為此制訂統(tǒng)一的架構(gòu)原則，就會(huì)使得團(tuán)隊(duì)人員根據(jù)自己的意愿來(lái)隨意選擇解決方案。即使某個(gè)開(kāi)發(fā)人員選擇的解決方案或許是最優(yōu)的，但由于系統(tǒng)存在多種不同的解決方案，就可能使得整個(gè)系統(tǒng)陷入混亂之中。例如，在我曾經(jīng)看到過(guò)的一個(gè)系統(tǒng)中，就存在不一致的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)解決方案。在同一個(gè)系統(tǒng)中，模塊A使用了Spring的JDBC模板訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)，而模塊B則直接使用了JDBC。還是在這個(gè)系統(tǒng)，模塊C通過(guò)使用JDK的map來(lái)緩存頻繁讀取的值，而在模塊D中卻又使用了開(kāi)源的EhCache作為緩存。

　　為了保證解決方案的一致性，除了需要事先制訂統(tǒng)一的架構(gòu)原則之外，前面提到的風(fēng)格一致性也能夠給予統(tǒng)一的指導(dǎo)和約束。事實(shí)上，我們可以將解決方案的一致性理解為對(duì)風(fēng)格一致性的一種實(shí)現(xiàn)。除此之外，團(tuán)隊(duì)成員之間的協(xié)作與溝通，以及必要的架構(gòu)評(píng)審與代碼走查，都能夠在一定程度上避免解決方案的不一致。

　　形式的一致性

　　保持系統(tǒng)架構(gòu)在形式上的一致性，常常是架構(gòu)師的有意為之，其目的是希望保持架構(gòu)的簡(jiǎn)單性。最能體現(xiàn)形式一致性的一個(gè)原則是“慣例優(yōu)于配置”。這里所謂的“慣例”，可以理解為框架對(duì)實(shí)現(xiàn)的一些約束。我們可以根據(jù)事先制訂的默認(rèn)規(guī)則，通過(guò)反射技術(shù)完成對(duì)象的創(chuàng)建，對(duì)象的協(xié)作，甚至是應(yīng)用程序的組裝。“慣例優(yōu)于配置”的關(guān)鍵，就在于它規(guī)定了形式上的一致性。以Ruby on Rails為例，通過(guò)事先確立Model、View和Controller的目錄結(jié)構(gòu)與命名規(guī)范，強(qiáng)迫開(kāi)發(fā)人員對(duì)系統(tǒng)進(jìn)行MVC的劃分，并嚴(yán)格遵守框架制訂的規(guī)范。在程序運(yùn)行時(shí)，Rails會(huì)將分離的部分組裝在一起。組裝的過(guò)程默認(rèn)按照命名約定與慣例進(jìn)行，在一般情況下就不需要任何外部的元數(shù)據(jù)配置信息。下圖是Rails的MVC架構(gòu)：

　　當(dāng)客戶(hù)端向服務(wù)端發(fā)出請(qǐng)求后，Dispatcher會(huì)對(duì)請(qǐng)求的url進(jìn)行解析，并判斷應(yīng)該將請(qǐng)求發(fā)送到應(yīng)用程序的哪個(gè)部分，以及如何解析這一請(qǐng)求。在尋找到正確的controller與action之后，就可以通過(guò)該action來(lái)處理請(qǐng)求。action可以查閱請(qǐng)求中攜帶的數(shù)據(jù)，可以與模型交互，也可以調(diào)用別的action。最后，action會(huì)為視圖準(zhǔn)備充分的信息，視圖則將所需的信息展現(xiàn)給用戶(hù)。因?yàn)樵谛问缴夏軌虮３忠恢滦裕蚣芫妥兊煤?jiǎn)單，參與的各個(gè)組件能夠做到各司其職，職責(zé)清晰，意圖明確。

　　這種形式的一致性基于一種樸素的思想，就是有限的約束比完全的開(kāi)放更容易實(shí)施和遵循。正如社會(huì)總要有一套被人廣泛認(rèn)同的規(guī)則，來(lái)約束每位公民的行為，否則整個(gè)世界就會(huì)亂了套。形式一致性的本質(zhì)在于概念的完整性，而它的基礎(chǔ)則在于約定。架構(gòu)的復(fù)雜性在于我們無(wú)法為混沌的系統(tǒng)做出正確的決策，如果能夠?yàn)槲覀兯鉀Q的場(chǎng)景抽象出整體的概念，就能夠最大程度地對(duì)模型進(jìn)行簡(jiǎn)化，從而給出一致性的約定。Rails利用現(xiàn)有的MVC模式，通過(guò)約定與慣例在形式上的一致性，實(shí)現(xiàn)了Web架構(gòu)的簡(jiǎn)化。如果我們觀察Maven的目錄結(jié)構(gòu)，就會(huì)發(fā)現(xiàn)Maven在針對(duì)依賴(lài)管理這樣一個(gè)場(chǎng)景，同樣提出了自己的概念模型，并在形式上規(guī)定了架構(gòu)的一致性：

　　簡(jiǎn)潔的架構(gòu)常常能體現(xiàn)一種獨(dú)到的美，而具有一致性的架構(gòu)則會(huì)給軟件系統(tǒng)帶來(lái)和諧與平衡。架構(gòu)風(fēng)格的一致可以保證系統(tǒng)架構(gòu)的統(tǒng)一，設(shè)計(jì)人員只要抓住了架構(gòu)的風(fēng)格特征，就能夠把握這個(gè)系統(tǒng)的“神”，從而促進(jìn)對(duì)系統(tǒng)架構(gòu)的理解。對(duì)架構(gòu)風(fēng)格的重視，還有利于架構(gòu)級(jí)別的資源重用，通過(guò)對(duì)問(wèn)題域的分析，判斷它應(yīng)該屬于哪一種架構(gòu)風(fēng)格的分類(lèi)，就能夠找到適合架構(gòu)的原則、模式或現(xiàn)有的平臺(tái)和框架。解決方案的一致性可以避免混亂的軟件架構(gòu)，促進(jìn)團(tuán)隊(duì)成員之間的交流與協(xié)作，規(guī)避因?yàn)榻鉀Q方案不一致而導(dǎo)致的資源浪費(fèi)。保持一致的解決方案還可以保障軟件質(zhì)量，因?yàn)楹芏酀撛诘碾[患與缺陷，恰恰都是因?yàn)椴煌慕鉀Q方案帶來(lái)的沖突導(dǎo)致的。形式的一致是簡(jiǎn)化的前提，并能夠保證系統(tǒng)概念的統(tǒng)一，通過(guò)抽象簡(jiǎn)化概念模型，并制訂一致的架構(gòu)約定，就能夠簡(jiǎn)化整個(gè)架構(gòu)體系，降低實(shí)現(xiàn)的難度。

it知識(shí)庫(kù)：軟件架構(gòu)的一致性，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。