架構不良的設計無品質上的考慮，可維護性極差，運維成本高。
良好的架構有助於功能的增刪改，任何一段**，放在架構的哪一層，都是由架構設計好的。任何一點變更，都要遵循自頂向下的原則，先考慮到架構，再考慮到底層**，而不是一上來就改**，加**。
那系統的品質又有那些呢？其實就是我們通常所說的效能、安全、可伸縮性等都會被定義的很好，而諸如可變性，可維護性，可用性等並沒有詳細規定，架構師在這方面應該更要加深理解，以更好的滿足品質的期望。
所以架構師的第一項任務就是和利益相關協作，理解這些品質的關注點和約束，並為他們排列優先順序。
具體的系統還會有其他的關注點：
功能性：產品向它的使用者提供哪些功能？
可變性：軟體將來可能需要哪些改變？
效能:產品將達到怎樣的效能？
容量：多少使用者可以併發使用該系統？該系統將為使用者儲存多少資料？
生態系統：在不是的生態環境中，該系統將於其他系統進行哪些互動？
模組化：如何將編寫軟體的任務分解為工作指派？特別是這些模組可以獨立的開發，並能準確而容易的滿足彼此的需要。
可構建性：如何將軟體構建成一組元件，並能夠獨立實現和驗證這些元件？哪些元件應該復用？
產品化：如果產品將以集中變體的形式存在，如何開發乙個產品線，並利用這些變體的共性？產品線中的產品以怎樣的步驟開發等等。
《架構之美》閱讀筆記02
1.新 的定位 一開始就有系統結構清晰的總體檢視，所以，新的功能單元可以新增到正確的功能區域，而不是為了一時方便，隨意新增。這樣，有的時候開發者的工作會需要動寫腦筋，但是在系統維護和擴充套件時，就變得容易了 2.系統的一致性 頂層設計的良好風格和決定，為底層 好處，是統 一 整潔的。清晰的定義，確保...
閱讀《架構之美》筆記02
在了解作者之後再說這本書。去架構設計乙個系統的時候，首先考慮的不是這個系統有多少個功能點，而應該是 1.執行在windows還是linux上，選擇的是tomcat還是jetty 2.你想支援的多少併發使用者的請求 3.是構建於內網還是外部易可訪問，需要怎麼樣的安全性要求 4.是吞吐量優先還是要求高響...
《架構之美》閱讀筆記02
首先我看了關於混亂大都市這一節，了解了微觀層面特點沒有統一的概念將不同的部分組織起，風格不一致控制流無法 即控制流的流向很複雜，額外的資料快取，其目的讓資料停留在更方便的地方 但是，容易造成資料的不一致性，維護或擴充套件不方便 沒有人了解整個系統，沒有任何文件，巨集觀層面特點，系統沒有彈性，無法變更...