軟體架構的一致性

　　在軟體設計階段，一定要統一團隊成員的架構思想和開發規範。下面推薦一篇文章：http://www.agiledon.com/?p=441，全文如下：

　　在Brooks的最新力作《設計原本(The Design of Design)》一書中，提及“一致性”對軟體的重要性。他認為：“一致性應該是所有品質原則的根基。好的架構應該是直接的，人們掌握了部分系統後就可以 推測出其他部分”。這種所謂“窺一斑而知全豹”的要求，實則是要求保持風格的一致性。

　　風格的一致性

　　許多軟體公司都會根據自身情況並結合業界規範制定符合本公司情況的編碼規範。例如對命名、格式等諸多風格的要求。這種編碼風格的一致性是相對容 易實現的。Brooks提到的一致性，更多地是體現架構風格的一致性。那麼，什麼是架構風格（Architecture Style)？在微軟撰寫的Application Architecture Guide 2.0一書中，將架構風格定義為一組原則的集合，是為系統家族提供抽象架構的粗粒度模式。架構風格可以改善設計，促進重用，為常見的問題提供可靠的解決方 案。而Mary Shaw對架構風格的定義則顯得更加晦澀一些：“架構風格根據結構組織的模式定義系統種類。更具體地說，架構風格定義組件和連接器類型的詞彙及它們如何進 行組合的一組約束。”顯然，Mary Shaw認為架構風格定義了架構組成元素的結構以及它們必須遵循的一些原則和約束。

　　架構風格可能是對一些架構模式的運用，然而在運用模式之前，首先需要分辨系統的類別。例如系統如果是業務複雜的公司專屬應用程式，那麼就領域層而言，就 應該選擇領域模型（Domain Model），通過有效地利用對象、組件和服務保證系統的可重用性與可擴充性。而一旦選擇了領域模型，那麼在通常情況下，就不應該在同一個系統的其他模組 中採用事務指令碼（Transaction Script）模式。否則，我們就違背了風格的一致性。

　　我們常常會將選定的架構風格作為整個系統架構的核心架構。瞭解了架構風格，就可以有助於瞭解整個軟體系統。例如，對於資料分析器系統而言，它的 核心邏輯是輸入資料流、輸出資料流與分析演算法之間的協作。由於分析演算法是對資料流的一種篩選和過濾，我們選定的架構風格是採用管道-過濾器（Pipes and Filters）模式。那麼，在瞭解資料分析器的架構時，只要掌握了管道-過濾器模式的核心思想，就能夠快速把握系統架構的核心。這有利於系統知識的延 續，並保證整個系統的一致性。

　　當然，架構風格的選擇會因為關注點的不同，產生不同的解決方案。例如，從部署的角度來看，我們可能需要選擇分布式部署的物理架構；而對於同一個 系統而言，由於需要考慮訊息的傳遞，我們又可能選擇訊息匯流排的方式。這與風格的一致性並不矛盾。我們只需保證在同一個關注面上，保持一致的風格即可。

　　解決方案的一致性

　　風格的一致性屬於軟體架構的層面，與之相似的是保證解決方案的一致性。在整個系統架構中，解決方案必須是一致的，否則就可能導致混亂的架構與代 碼。那麼，怎樣才能保證解決方案的一致性呢？首要條件是在進行系統架構之前，我們必鬚根據系統與團隊的情況，制定被團隊成員廣泛接受的架構原則。例如，我 們可以為系統制訂分層指導原則。對於領域層，我們遵循DDD的要求，為領域模型確定實體、值對象、彙總根、服務、工廠與資產庫之間的明確劃分，並明確地指 出它們應該具備的特徵。我們要求應用服務層不應包含任何商務邏輯，只負責UI與領域層之間的訊息傳遞，並可調用基礎設施中公用模組的資料驗證、緩衝和安全 等功能。我們要求應用服務層不應保留業務對象的狀態，僅僅負責協調應用的活動，並要求所有公開在外的應用服務均定義為介面。

　　在制訂了這樣的架構原則後，我們就可以統一系統的解決方案。例如遵循之前的分層指導原則，我們可以獲得如下的針對領域層的統一解決方案：

　　如果我們沒有保證解決方案的一致性，並為此制訂統一的架構原則，就會使得團隊人員根據自己的意願來隨意選擇解決方案。即使某個開發人員選擇的解 決方案或許是最優的，但由於系統存在多種不同的解決方案，就可能使得整個系統陷入混亂之中。例如，在我曾經看到過的一個系統中，就存在不一致的資料庫訪問 解決方案。在同一個系統中，模組A使用了Spring的JDBC模板訪問資料庫，而模組B則直接使用了JDBC。還是在這個系統，模組C通過使用JDK的 map來緩衝頻繁讀取的值，而在模組D中卻又使用了開源的EhCache作為緩衝。

　　為了保證解決方案的一致性，除了需要事先制訂統一的架構原則之外，前面提到的風格一致性也能夠給予統一的指導和約束。事實上，我們可以將解決方 案的一致性理解為對風格一致性的一種實現。除此之外，團隊成員之間的協作與溝通，以及必要的架構評審與代碼走查，都能夠在一定程度上避免解決方案的不一 致。

　　形式的一致性

　　保持系統架構在形式上的一致性，常常是架構師的有意為之，其目的是希望保持架構的簡單性。最能體現形式一致性的一個原則是“慣例優於配置”。這 裡所謂的“慣例”，可以理解為架構對實現的一些約束。我們可以根據事先制訂的預設規則，通過反射技術完成對象的建立，對象的協作，甚至是應用程式的組裝。 “慣例優於配置”的關鍵，就在於它規定了形式上的一致性。以Ruby on Rails為例，通過事先確立Model、View和Controller的目錄結構與命名規範，強迫開發人員對系統進行MVC的劃分，並嚴格遵守架構制 訂的規範。在程式運行時，Rails會將分離的部分組裝在一起。組裝的過程預設按照命名規範與慣例進行，在一般情況下就不需要任何外部的中繼資料配置資訊。 是Rails的MVC架構：

　　當用戶端向服務端發出請求後，Dispatcher會對請求的url進行解析，並判斷應該將請求發送到應用程式的哪個部分，以及如何解析這一請 求。在尋找到正確的controller與action之後，就可以通過該action來處理請求。action可以查閱請求中攜帶的資料，可以與模型交 互，也可以調用別的action。最後，action會為視圖準備充分的資訊，視圖則將所需的資訊展現給使用者。因為在形式上能夠保持一致性，架構就變得簡 單，參與的各個組件能夠做到各司其職，職責清晰，意圖明確。

　　這種形式的一致性基於一種樸素的思想，就是有限的約束比完全的開放更容易實施和遵循。正如社會總要有一套被人廣泛認同的規則，來約束每位公民的 行為，否則整個世界就會亂了套。形式一致性的本質在於概念的完整性，而它的基礎則在於約定。架構的複雜性在於我們無法為混沌的系統做出正確的決策，如果能 夠為我們所要解決的情境抽象出整體的概念，就能夠最大程度地對模型進行簡化，從而給出一致性的約定。Rails利用現有的MVC模式，通過約定與慣例在形 式上的一致性，實現了Web架構的簡化。如果我們觀察Maven的目錄結構，就會發現Maven在針對依賴管理這樣一個情境，同樣提出了自己的概念性模型， 並在形式上規定了架構的一致性：

　　簡潔的架構常常能體現一種獨到的美，而具有一致性的架構則會給軟體系統帶來和諧與平衡。架構風格的一致可以保證系統架構的統一，設計人員只要抓 住了架構的風格特徵，就能夠把握這個系統的“神”，從而促進對系統架構的理解。對架構風格的重視，還有利於架構層級的資源重用，通過對問題域的分析，判斷 它應該屬於哪一種架構風格的分類，就能夠找到適合架構的原則、模式或現有的平台和架構。解決方案的一致性可以避免混亂的軟體架構，促進團隊成員之間的交流 與協作，規避因為解決方案不一致而導致的資源浪費。保持一致的解決方案還可以保障軟體品質，因為很多潛在的隱患與缺陷，恰恰都是因為不同的解決方案帶來的 衝突導致的。形式的一致是簡化的前提，並能夠保證系統概念的統一，通過抽象簡化概念性模型，並制訂一致的架構約定，就能夠簡化整個架構體系，降低實現的難度。