美的核心在于概念完整性——即一組抽象和規則，在整個系統中盡可能簡單地應用它們。
我們將計算機系統的架構定義為一組最小的特征集它們決定了哪些程序將運行，以及這些程序將得到什么結果。
架構是一種折中——決定改進其中一個特征常常會對其他特征產生負面影響。架構師必須確定怎樣做是足夠好的，方法就是發現特定系統的重要關注點，以及充分滿足這些關注點的條件。
外部行為描述展示了產品如何與它的用戶、其他系統和外部設備進行交互，這應該表現為需求。結構描述展示了產品如何劃分為多個部分，以及這些部分之間的關系。我們還需要內部行為描述，用于描述組件之間的交互接口。結構上的描述常常展示相同部分的一些不同視圖，因為不可能把所有信息以有意義的方式組織到一張圖紙或一份文檔中。一個視圖中的組件，可能是另一個視圖中一個組件的一個部分。
典型的利益相關人和他們的關注點包括：
? 投資人，他們想知道項目是否能夠在給定的資源和進度約束下完成。
? 架構師、開發人員和測試人員，他們首先考慮的是最初的構建和以后的維護與演進。
? 項目經理，他們需要組織團隊，制定迭代計劃。
? 市場人員，他們想通過品質特點實現與競爭者的差異化。
? 用戶，包括最終用戶、系統管理員，以及安裝、部署、準備、配置人員。
? 技術支持人員，他們關注幫助平臺電話呼入的數目和復雜性。
架構師的第一項任務，就是與利益相關人協作，理解這些品質關注點和約束，并為它們排列優先級。
重要關注點包括：
? 功能性
? 可變性
? 性能
? 容量
? 生態系統
? 模塊化
? 可構建性
? 產品化
? 安全性
架構結構
? 信息隱藏結構
模塊間最基本的關系是“整體-部分”關系。第二種信息隱藏模塊結構是基于程序和模塊之間的“包含”關系。
滿足的關注點：信息隱藏結構的設計應該能滿足可變性、模塊化和可構建性的要求。
? 使用結構
使用結構確定了我們可以構建并測試怎樣的工作子集。
滿足的關注點：產品化和生態系統
? 進程結構
信息隱藏結構與使用結構屬于靜態結構，進程結構屬于運行時結構。
滿足的關注點：性能和容量
? 訪問結構
如果這種結構讓程序訪問的權限最小化，并且嚴格執行，我們就認為系統更安全。
滿足的關注點：安全性
美麗的架構展示了一些普遍原則：
? 一處一個事實
? 自動傳播
? 架構也包含構建
? 最少量機制
美麗的架構不會追求最佳，使用最少的機制來滿足整體的需求。找到每種情況下的最佳會導致各種容易出錯的機制的產生，而用極簡的方式來添加機制則會得到更小的、更快的、更健壯的系統。
? 構建引擎
高度可復用
? O(G)，增長的階
? 抵制熵增
簡而言之，美麗的架構用更少的機制做更多的工作。
架構是一種很浪費空間的藝術。
軟件系統就像一座由建筑和后面的路構成的城市。
重要的是要保持軟件設計的品質。壞的架構設計會導致更壞的架構設計。
極限編程（XP）沒有貶低設計，它貶低的是不必要的工作。
架構有助于定位功能：添加功能、修改功能或修復缺陷。它為你提供了一個模板，讓你將工作納入到一張系統導航圖中。
清晰的架構設計將導致一致的系統。所有決定都應該在架構設計的背景下做出。
軟件架構不是一成不變的。需要時就改變它。要想做到可以修改，架構就必須保持簡單。犧牲簡單性的修改要抵制。
延遲設計決定，直到你必須做出這些決定為止。不要在你還不知道需求的時候就做出架構決定。不要猜測。
必須保持架構品質。只有當開發者們相信它并對它負責時，才能做到這一點。
你的系統應該有一組不錯的自動化測試，它們讓你在進行根本的架構變更時風險最小。這為你提供了工作的空間。
對你的代碼進行單元測試將帶來更好的軟件設計，所以設計時要考慮可測試性。
好的項目計劃將帶來優質的設計。分配足夠的時間來創建架構杰作，它們不會立即出現。
團隊的組織方式必然對它產生的代碼有影響。隨著時間的推移，架構也會影響到團隊協作的好壞。當團隊瓦解時，代碼的交互就很糟糕。當團隊協作時，架構就集成得很好。
好的架構是很多因素的結果，包括以下方面（但不限于此）：
? 確實進行有意為之得前端設計。
? 設計者的素質和經驗。
? 在開發過程中，保持清晰的設計觀點。
? 授權團隊負責軟件的整體設計，而團隊也承擔起這一責任。
? 不要害怕改變設計：沒有什么是一成不變的。
? 讓合適的人加入到團隊中，包括設計者、程序員和經理，確保開發團隊的規模合適。確保他們具有健康的工作關系，因為這些關系將不可避免地影響代碼的結構。
? 在合適的時候做出設計決定，當你知道所有必要信息時再做出決定。延遲那些暫時不能做出的決定。
? 好的項目管理，以及合適的最后期限。
絕不要失去神圣的好奇心。——愛因斯坦
在線游戲和虛擬世界顯然已經找到了辦法來實現伸縮性，以應對數量巨大的用戶。目前分為兩類方法：
第一類實質上是基于地理位置來實現的。第二種處理游戲或虛擬世界中擁塞區域的方法叫做分區。
