原文鏈接：The Pragmatic Architect - To Boldly Go Where No One Has Gone Before

　　本文首次發表在 IEEE Software ，并由 InfoQ 和 IEEE 計算機協會為您引進。

　　是什么讓架構師們精通自己的技藝？熟練的架構師是如何進行設計的？一次次，有人問起我這些問題，而我也不止一遍的問我自己。很明顯，這并不只是軟件工程過程、設計方法、技術或是編程的專業程度所決定的。很多架構師具備令人欽佩且完備的技術知識，這確實是使設計成功的必要條件。但是，還是有很多的軟件項目失敗了，或是在項目的架構中遭受到了嚴峻的挑戰。掌握此道的關鍵在于架構師是以什么方式實現設計，他們重視什么，他們關注哪些方面以及在這些方面努力著。

　　（缺失的）線條能告訴我們什么

　　圖1展示了摘自以前項目的一張高層次圖表，那個項目的架構師創建了該圖以闡述系統的基本設計。

　　該圖大致描述了系統的關鍵組件、各組件的職責以及它們核心的模塊化原理。架構師使用這些概要圖來交流設計，以管理開發的過程，并以此討論它們在業務方面產生的影響，例如：成本、時間和精力等。然而，一段時間后，管理層會想要知道項目為什么會有重大延期以及預算為什么會超支，他們無法從架構師的報告中獲得任何提示或指標。

　　問題來自于該圖上的點狀黑線以及那些“尚未顯示的線條”。這些點狀黑線表示了該項目開發的一個專有的消息中間件。在圖上無法找到所羅列的這些組件之間的通信關系，特別要強調的是，這些關系是通過這個中間件運作的。該項目的架構師并不認為值得對這些方面值建模或報告，因為從他們的視角來看，它們代表的是基本技術的基礎設施，并不會有助于系統的領域和業務用例。然而，中間件的開發消耗了大量預算，因為這個過程中涉及到很多健壯性和性能的問題，我們不得不從系統的其他部分中抽調最好的開發人員來解決這些缺陷。另外，支撐這些中間件問題也需要在領域組件中付出相當多的努力。

圖1.一幅用于和業務利益相關者交流關鍵設計的高層次架構概要圖

　　事物間的設計

　　過往的經驗顯示，系統的架構師們常常將注意力過多地集中于一些“明顯”的事物上：用戶接口、領域特定組件、數據管理以及持久化等。然而架構的問題并不在組件之內，而是在組件之間：與其他系統之間的接口，交互以及集成——包括底層的技術基礎設施。但是架構規范里幾乎不涉及這些方面，所以在這些方面發生問題之前，架構師和開發人員都不會給予關注。

　　與此相反，注重實效的架構師們更關注事物之間的事物——就是說，組件之間的事物以及代碼行（LOC）之間的事物，例如標準數據類型背后的領域思想。當然，他們也會指導系統實際組件的設計，但是當指導通常足夠充分以支持更進一步拆分并且可由開發團隊實現時，這些事物之間的事物實際上需要架構師們親手處理。而且必須是他們，這是他們的領域——特別是在我們還不確定如何實際地設計這些“事物”時。下面讓我們去探究一下注重實效的架構師們的秘密。

　　發現隱藏的領域概念

　　最近我在我們的幾個系統的代碼上運行tag-cloud生成器。我想通過這種方式對這些系統中重要的領域概念有個大致的印象。出人意料的是，在這些系統中最頂端的數據類型是 string 和 int。然而我懷疑是不是真的如此，因為在針對工業工程或能源管理的系統中，其他概念會更加重要：設備、電力線、傳感器、制動器、標簽、警報等等。當我更深入地查看代碼時，就發現了這些領域概念——但是它們分散在表面上幾乎不怎么相關的諸如 string 和 int 這樣基本類型的配置中。

　　如此隱藏的領域概念可能需要開發者們花費相當多的努力來理解和實現系統，以保證產品的質量。我如何才能知道一個 int 實際表示的是某個特定的領域概念？我如何保證在某個特定的計算上下文中使用 int 時會執行特定領域概念的契約？我不能，除非通過注釋和約定，其他的都對實踐沒有實質幫助。圖2展示了摘自導致 Ariane 5 在其 1996 年首飛時墜毀的（標有注釋的）代碼片段，其根本原因是源于對整型數溢出的保護不足。

圖2. 摘自 Ariane 5 的代碼片段。因為對整型數溢出的保護不足導致了 Ariane 5 在其 1996 年首飛時墜毀。

　　我們有足夠的勇氣說，如果開發者以定義好的方式使用契約，將速度建模成一種合適的類型，那么 Ariane 5 的軟件錯誤原本是可以避免的。然而這個例子也很好的把握了顯式建模的重要性。

　　即使領域概念很明顯、很清楚，但也可能埋藏在無數的細節之下。舉個例子，我曾經研究過一個系統的復雜性。該軟件包含了一個命名服務，該服務擁有一個包括 300 多種方法的接口。該服務的實際契約已經幾乎看不清楚，而開發者們需要非常努力才能正確和有效地使用它。有分析表明，不超過 20 個方法就完全可以說明一個服務的必要契約。

　　注重實效的架構師因此會非常重視并做好相關的工作，在他們的架構中對所有領域概念進行明確的描述，例如那些常被粗粒度描述的組件，細微的特定領域的數據類型，有意義的接口，等等。在對概念的建模中，注重實效的架構師總是專注于精簡而避免混亂或復雜，并著重強調概念的本質。這樣一來，系統中那些隱藏的概念或是相關的性能都會立即明朗起來，這將會幫助開發人員更好的識別它們，并把它們看作獨特的、明確的、有意義的類型（types）。用途（Usage）轉變成類型——對于創建有表現力的軟件設計和健壯的實現來說是一種重要的實踐。

　　在事物銜接之處

　　什么是架構？Eoin Woods 對于該問題思考了相當長一段時候后找到了一個答案。“那些很多被架構師每天在使用著的思想：框架，代理，層次，接口，消息通知，連接器…這都是與間隙（gaps）相關的！[...] 架構是一種用于連接軟件設計師們一起工作的粘合劑，共同創造一個彈性的、靈活的、可擴展的以及最終可用的系統。” 

　　在這個結論中包含著很多道理。我確定所有人都知道關于組件接口不支持工作流，而我們系統不得不支持的事。在很多項目中，集成——無論是系統集成還是“僅僅”是系統構成組件的集成——是成本最高的地方。而間隙（gaps）是指事物間銜接處的空間，組件交互的地方——沒有一方會對其負責，除了注重實效的架構師！所以設計簡潔及有意義的組件接口來支持組件間工作流的實現確實是不平凡的任務。在組件間定義符合用戶在系統上執行任務那樣的交互是一件困難的事。甚至更難的是將一個系統與其他系統集成，使其在不喪失任一相關系統獨立質量的情況下支持跨系統的工作流。你可以快速瀏覽一下支持該結論主題方面的模式著作。

　　“空隙（void）”事實上需要架構師更多的關注和親身實踐。然而重點并非事物之間的適配——接口，交互，組件，系統——這些肯定是要連接的；重要的是隨著對工作流的支持之后這些事物之間的協調性。目標是最精益（leanest）的適配，并且最深刻（impressive）的映射！這就是架構產生的地方；此處的決策將對系統的生命周期成本產生非常大的影響。本段開篇提到的戰爭故事也就恰好定格在這里：事物在哪里銜接。

　　我們可以對獨立系統間那些“在中間（in-between）”的所有類型的工件的設計思想進行擴展——舉個例子，駐留于不同計算節點上，在不同的進程中或是在不同的線程中各個部分。我曾看到過一些失敗的項目，之所以失敗是因為在他們的處理實體（processing entities）之間粘合的時候采用了一種幼稚的方式。其實在跨越計算機、進程和線程的分布式實體之間建立工作交互比較簡單。這就是對設計的掌控，無論如何，創建（分布式）進程之間的交互可以最小化網絡交互和對線程間同步的需求。

　　以不確定作為驅動

　　我們都會抱怨那些模糊的系統需求。然而縱使業務的利益相關者們進行了最仔細的需求捕獲工作，這都無法完全解決所有的歧義和不確定性：這就是事實。同樣，軟件工程師可能需要針對特定的需求費心選擇各種可選解決方案，并在討論該采用哪種方案上花費大量時間。但是架構師則必須要面對來自設計、開發以及交付系統帶來挑戰，并且在系統發布和后續的整個生命周期中都能保證滿足相關的業務需求。系統開發的時間越長，系統的生命周期越長，不確定性也就越大。

　　在這種形勢下，架構師們會選擇一種最典型的規避方式，那就是泛型——它可以最大程度地帶來靈活性。架構通過彈性機制來應對過載，這在理論上支持所有可想象的系統配置，但是并不能滿足任何有意義配置的具體（非功能性）需求。

　　注重實效的架構師能察覺到危險地帶并以不確定性為驅動來做好決策。首先，他們承認需要在各種可選項中做好選擇，并針對他們設計中的可變方面做出工作，以此來限制變化或選擇造成的影響。他們會深入探索系統的使用場景，以此來澄清需求中的不確定性或對一種特殊設計選項的選擇，從而實現出場景的原型或可運行骨架系統（walking skeleton）的一個部分。并且，他們非常歡迎來自于原型和可運行骨架系統的循環反饋，以驅動或調整他們的決策。架構師們重復地在事物之間（本例中是指在有歧義和不確定的需求或可選設計選項之間）進行著設計。

　　本文的標題是“大膽行前人未行之路”，架構設計恰好就需要如此。來到事物之間：在代碼行上或其間，發現隱藏的領域概念；在你的系統和其他系統的組件之間，可以引導你設計好接口和工作流；在不確定性及可選項之間，驅動你的決策。架構師的工作就是去盡早地發現這些“在中間的”事物，使它們更加明確，從中做出決策。以上這些加上扎實的有關架構方法和技術的專業知識，以及謹慎的實踐，就是對架構的精通之道：在軟件系統的痛點上進行深思熟慮并最終決定它的成敗。

　　參考文獻

1. J-J. Levy， "Un Petit Bogue, Un Grand Boum!" (in French)， 2010.
2. J-L. Lions et al.， "Ariane 501 Inquiry Board Report," 1996.
3. E. Evans, Domain Driven Design, Addison- Wesley， 2004.
4. F. Buschmann and K. Henney， "Five Considerations for Software Architecture, Part 1, IEEE Software, vol. 27, no. 3, 2010, pp. 63-65.
5. E. Woods, "Architecting in the Gaps," 2011.
6. F. Buschmann, "Unusable Software Is Useless, Part 1," IEEE Software, vol. 28, no. 1, 2011, pp. 92-94.
7. F. Buschmann, K. Henney， and D.C. Schmidt, Pattern-Oriented Software Architecture-A Pattern Language for Distributed Computing, John Wiley and Sons, 2007.
8. G. Hohpe and B. Woolf, Enterprise Integration Patterns-Designing, Building, and Deploying Messaging Solutions, Addison-Wesley， 2003.
9. F. Buschmann, "Learning from Failure, Part 2: Featuritis, Performitis, and Other Diseases," IEEE Software, vol. 27, no. 1, 2010, pp. 10-11.
10. K. Henney， "Use Uncertainty as a Driver," 97 Things Every Software Architect Should Know， R. Monson-Haefel, ed.， O’Reilly， 2009, pp. 321-361.