軟體架構的設計受到許多因素的制約，架構是好是壞並沒有統一的標準。這取決於人們對軟體的需求、軟體被構建和執行的環境，以及軟體團隊本身的特點等等因素。評價軟體好壞有很多指標，例如效能、安全、可伸展性等等。一般來說，這些指標是很難全部滿足的，試圖改進其中乙個往往會對其他指標產生負面影響。所以從某種意義上來說，軟體架構是折中的遊戲。對於一組功能需求和品質需求，沒有唯一的正確架構。
《架構之美》沒有太多空洞的概念和論述，而是拋磚引玉地展示多個實際的專案。通過對它們架構利弊的分析，以及相關的思考，給讀者提供了有益的啟發
書中提到了很多有關乙個優秀的架構師應該具備的品質很吸引我的眼球，好的架構師首先關注的並不是系統的功能而是系統需要滿足的品質，它指明了功能以何種方式交付才能被系統的利益相關者普遍接受，系統的結果包含了這些stakeholders的既定利益。成功的架構師的兩項重要實踐是：讓利益相關者參與和同時關注系統的功能的品質和功能。
書中介紹了什麼樣的的架構才算是美麗的架構，美麗的架構在開始時，要關注其實用性，好的架構應該是每天被很多人使用的；使用架構之前，我們還要考慮它必須要能夠被構建（可構建性）；接下來就是關注架構的可永續性，好的架構應該能夠經得起時間的考驗，能夠考慮到未來的變更，允許期望的修改；最後，要尋找一些能讓人高興的架構（開發人員、測試人員、使用者等），這就要求架構必須滿足概念完整性，這樣的架構才易懂，易用，才會做到簡單而又不過於簡單。幾個比較常見的美麗架構的例子有：a-7e艦載飛行處理器的架構；朗訊5ess**交換機軟體架構；全球資訊網；unix系統。
在後來的章節中，又介紹了「混亂大都市」和「設計之城」兩個專案，將兩種比較，形象的說出了好的架構與差的架構的一些特性。「混亂大都市」的最大問題是重複，它沒有考慮好軟體設計中最關鍵的品質，內聚和耦合。它的失敗經驗很值得我們借鑑：缺乏預見性和對架構的整體思考。版本的發布週期過於漫長；系統沒有彈性，可擴充套件性差；**問題很嚴重，沒有統一的命名規則和命名結構，導致新員工面對複雜的**結構，感覺壓力比較大，從而又造成了員工的跳槽和士氣低等問題；團隊的內部政治問題嚴重，沒有團結精神，缺少凝聚力。
《架構之美》閱讀筆記02
1.新 的定位 一開始就有系統結構清晰的總體檢視，所以，新的功能單元可以新增到正確的功能區域，而不是為了一時方便，隨意新增。這樣，有的時候開發者的工作會需要動寫腦筋，但是在系統維護和擴充套件時，就變得容易了 2.系統的一致性 頂層設計的良好風格和決定，為底層 好處，是統 一 整潔的。清晰的定義，確保...
《架構之美》閱讀筆記01
1丶架構是什麼 架構應該是一組結構，於一組設計規則，能減少複雜性。常見定義是，每種結構由各種型別的元件和關係組成，它們如何組合 相互呼叫 通訊 同步 及其其他互動。元件及元件之間的關係 2丶架構目的 確保利益相關人員的關注點能夠得到滿足，而在構想 計畫 構建和維護系統時，系統架構能夠處理複雜性。為了...
架構之美閱讀筆記03
在後來的章節中，又介紹了 混亂大都市 和 設計之城 兩個專案，將兩種比較，形象的說出了好的架構與差的架構的一些特性。混亂大都市 的最大問題是重複，它沒有考慮好軟體設計中最關鍵的品質，內聚和耦合。它的失敗經驗很值得我們借鑑 缺乏預見性和對架構的整體思考。版本的發布週期過於漫長 系統沒有彈性，可擴充套件...