在後來的章節中，又介紹了「混亂大都市」和「設計之城」兩個專案，將兩種比較，形象的說出了好的架構與差的架構的一些特性。「混亂大都市」的最大問題是重複，它沒有考慮好軟體設計中最關鍵的品質，內聚和耦合。它的失敗經驗很值得我們借鑑：缺乏預見性和對架構的整體思考。版本的發布週期過於漫長；系統沒有彈性，可擴充套件性差；**問題很嚴重，沒有統一的命名規則和命名結構，導致新員工面對複雜的**結構，感覺壓力比較大，從而又造成了員工的跳槽和士氣低等問題；團隊的內部政治問題嚴重，沒有團結精神，缺少凝聚力。
相比之下，「設計之城」的成功就是吸取了它的經驗教訓，從一開始，專案的目標就很明確，在以後的開發過程中的**必須支援所設定的要完成的功能，這樣就形成了乙個通用的目標的**集，在以後的使用過程中可以適用於很多產品的配置。開發團隊動態的遵守架構設計，開發人員們密切合作，共同建立一組乾淨、一致、密切合作的軟體。如何conway法則中所說的，團隊的組織方式也如同軟體的組織方式；堅持保持品質的信念；
要有單元測試和很好的自動化測試。它的裡面提到了乙個新的原則：yagni（you aren』t going to need it）即在你不需要他的時候，不要急著先去設計它。這大大提高了架構的品質，在設計之初只是設計系統中最重要的部分，餘下的部分延遲到需要的時候再進行分析和設計，這樣可以很好的解放思想。
乙個好的架構的形成不僅是架構師的功勞，還有團隊的集體合作，主要因素：確實進行有意為之的前端設計；設計者有很好的素質和經驗；在開發過程中，保持清晰的設計觀點；授權團隊負責軟體的整體設計；不要害怕改變設計；讓合適的人加入到團隊中，讓團隊保持健康的工作關係；在合適的時候做出決定；好的專案管理和合適的最後期限。
在介紹資料增長對架構影響的時候以以facebook為例，說明了facebook的獨特平台是如何解決了資料迅速增長的情況下系統的架構是如何維持穩定的。facebook的獨特平台主要是有一下幾個部分組成的：
facebook api是為了實現通過乙個外部可以訪問的web服務來提供facebook資料，實現應用可以利用在facebook上的使用者社會關係資料，但是不能直接訪問。
facebook的fql的提出是為了解決從其平台api獲取資料比獲取內部資料的開銷大得多的問題，fql提供的是一種查詢服務。類似內部資料採用的模式，實現外部資料訪問模式。它能讓開發者更快的處理它的請求，能夠以比api更好的力度來訪問資料，同時保持了sql類似的語法。
fbml的提出時基於這樣乙個實際問題：對於社會關係應用來說，要獲得引人注目的關鍵性使用者數，支援它的社會關係網路上的使用者必須要能注意到其他使用者在利用這些應用進行互動；外部應用不能夠使用facebook沒有通過web服務暴露出來的哪些核心資料元素。fbml是一種資料驅動的標記語言，在社會關係站點上建立應用執行和顯示的內容，讓使用者在乙個受信任的環境下操作。
《架構之美》閱讀筆記02
1.新 的定位 一開始就有系統結構清晰的總體檢視，所以，新的功能單元可以新增到正確的功能區域，而不是為了一時方便，隨意新增。這樣，有的時候開發者的工作會需要動寫腦筋，但是在系統維護和擴充套件時，就變得容易了 2.系統的一致性 頂層設計的良好風格和決定，為底層 好處，是統 一 整潔的。清晰的定義，確保...
《架構之美》閱讀筆記01
1丶架構是什麼 架構應該是一組結構，於一組設計規則，能減少複雜性。常見定義是，每種結構由各種型別的元件和關係組成，它們如何組合 相互呼叫 通訊 同步 及其其他互動。元件及元件之間的關係 2丶架構目的 確保利益相關人員的關注點能夠得到滿足，而在構想 計畫 構建和維護系統時，系統架構能夠處理複雜性。為了...
架構之美閱讀筆記01
為什麼要學習架構？之前，老師教我們軟體架構的時候，就告訴我們，軟體開發，先從架構入手。他說，弄清楚了架構，再來學習具體的語法和技術就很簡單了。以前不懂，底層具體的細節都不了解，如何來構建乙個系統呢？就像讓我們去建造一棟大廈，剛開始想到的可能就是需要磚 砌牆的工具 這就像剛學習程式設計的自己，以為掌握...