一、軟件架構的定義
軟件架構是開發項目和系統的藍圖，定義了必須由設計和實施團隊執行的工作任務。架構是系統質量的主要載體，例如性能，可修改性和安全性，如果沒有統一的架構願景，這些都不能實現。架構是用於項目早期分析的工件，以確保設計方法將產生可接受的系統。通過構建有效的體系結構，我們可以識別設計風險並在開發過程的早期緩解它們。
二、架構介紹的引子
對於開發人員來說，在沒有正式架構的情況下就開始對應用程序進行編碼是非常普遍。如果沒有清晰且定義明確的架構，大多數開發人員和架構師將採用事實上的標準：傳統的分層架構模式（也稱爲n-tier架構），通過將源代碼模塊分離爲包來創建隱式層。 不幸的是，這種做法經常會導致缺乏組織的源代碼模塊，這些模塊缺乏明確的角色，職責和彼此之間的關係。這通常被稱爲架構的反面模式：大泥球（big ball of mub）。
缺乏正式架構的應用程序通常緊密耦合，易碎，難以更改且沒有清晰的視野或方向。最終結果，如果不完全瞭解系統中每個組件和模塊的內部工作，就很難確定應用程序的體系結構特徵。關於部署和維護的基本問題都很難回答：體系結構是否可擴展？應用程序的性能特徵是什麼？應用程序對更改的響應有多容易？應用程序的部署特徵是什麼？架構的響應速度如何？
架構模式有助於定義應用程序的基本特徵和行爲。例如，某些架構模式天生地適合於高度可擴展的應用程序，而其他架構模式天生地適合於高度敏捷的應用程序。爲了選擇滿足我們特定業務需求和目標的架構，必須瞭解每種架構模式的特徵，優點和缺點。
作爲架構師，我們必須始終證明自己的架構決策合理，尤其是在選擇特定架構模式或方法時。《Software Architecture Patterns》的目的就是爲我們提供足夠的信息，讓我們合理化地選擇特定架構模式或方法。
說明：這一部分翻譯自《Software Architecture Patterns》by Mark Richards的Introduction部分，版本信息：2017-06-22，第三次發佈。
三、模式對風格
在架構模式之上還有架構風格這一層概念。
區分架構模式和架構風格是有好處的。模式針對的層面比風格針對的層面要小一些。模式在設計中隨處可見，在同一個設計中，可以出現多種模式。相反，一個系統通常只有一個主導的架構風格。
架構風格和架構模式之間的區別有時並非那樣清晰，肯定可以找到一些兩者難以區分的例子。系統的規模越大，所謂“系統的系統”就很常見，即獨立的系統會成爲更大系統的一個組成部分。原先獨立的系統有自己的架構風格，但現在卻從屬於一個更大規模系統的架構風格，在這種情況下，自己原先的架構風格不是很有可能降成爲一種架構模式嗎？所以，不要擔心應該把某些東西歸類爲一種術語、一種設計模式、一種架構模式，還是一種架構風格，爲了保險起見，我們可以把它們都稱爲模式，或許，我們還可以把架構模式和架構風格當做同義詞。
說明：這一部分摘自《恰如其分的軟件架構-風險驅動的設計方法》2013年9月第1版的14.4章節。