16、不要在一棵樹上吊死
負責構建系統的人似乎無法接受這樣的事實：沒有哪種資料型別、訊息格式、訊息傳送機制，甚至主流的架構元件、策略、觀點用來能夠用來解決所有的業務問題，畢竟當大家都希望擺脫業務需求不斷滋生的意外和煩惱。
才用多鐘表現方式、多鐘傳輸方式不是為了消遣。應當認識到，通過分解系統的非功能引數，可以為客戶提供多樣化的解決方案。
17、業務目標至上
在商業化的背景下開發企業應用，架構師必須成為業務部門和技術部門溝通的橋梁，周旋調解，兼顧雙方利益，同時業務目標來驅動專案 開發。業務目標和實際的開發條件應該成為架構師主持制定決策的參照系統。
在啟動乙個軟體專案之前，應當制定計畫，明確投資回報的預期。架構師必須把握這個預期，並預估該項目的商業價值，避免做出錯誤的技術決策，造成經費超支。
用業務目標驅動專案開發，才能保證軟體開發團隊的長遠利益。
18、先確保解決方案簡單可用，再考慮通用性和復用性
許多用來實現基礎設施的**，包括組建、框架、類庫、基礎服務，普遍存在乙個問題，它們設計一向強調通用性而不考慮具體應用。
如果存在多個可實施方案難以取捨，「先簡單後通用」原則可以成為最終的評判標準。
雖然很多架構師重視通用性，但這樣做是有前提條件的。並非所有人都需要通用性，願意為它掏錢。
19、架構師應該親力親為
稱職的架構師應該通過示範領導團隊，架構師通常都取得過不錯的業績，有份出彩的簡歷，容易獲得業務人員和技術人員的青睞。但除非他能展示自己的實踐能力，否則很難贏得團隊的尊重，團隊成員將無法從他身上學到東西，大家甚至難以在他的領導下做好本職工作。
20、持續整合
架構師（無論是應用架構師還是企業架構師）都應該在專案中鼓勵推廣持續整合的方法和工具。
現在持續整合已經取代了「盡早構建，經常構建」（build early and often）的提法，它確保當前的開發不會出現意外，是一種降低風險的技巧。
構建應用程式是持續整合最主要的內容，它通常是自動執行的，可以設定在夜裡執行，或者當源**改變時自動觸發。當然你也可以選擇手動構建。
21、避免進度調整失誤
導致專案失敗的原因很多，最常見的是中途臨時調整進度。
改變計畫回答帶來以下問題：
倉促的進度會導致拙略的設計、蹩腳的文件，可能引發質量問題，導致使用者拒絕簽收
倉促完成**導致bug增多，測試不充分增加測試中可能出現的問題
以上問題均能引發產品質量問題，而解決產品質量的問題代價更高。最後的結果是成本不降反公升，通常專案就是這樣失敗的。
22、取捨的藝術
架構師應該明白魚和熊掌不可兼得的道理。如果2個效能本身就是衝突的，滿足一項就會導致另一項失敗或者整體失敗。
23、打造資料庫堡壘
建立牢固的資料模型要從第一天開始
牢固的資料模型既可以保障當前的資料的安全，又為今後提供可擴充套件性。要保障資料安全就必須隔離來自應用層的bug（在不斷變化的應用層中這些bug無處不在，不會因為你的勤奮而消失），必須嚴格遵守引用完整性規則，盡量使用域約束規則，還要選擇恰當的鍵，即保證資料的完整性，又遵守約束規則。要實現可擴充套件性，就必須正確地將資料標準化。以便今後在資料模型上新增架構層：千萬不要偷懶走捷徑。
為了妥善保護資料庫必須拒絕無效資料，阻止無意義的關係。在定義鍵、外來鍵、域約束時，應該採取簡潔的容易被理解和驗證的名稱，使他們含義不言自明。資料模型中的域規則也要做到物理化和持久化，避免他們在應用邏輯發生改變時被刪除。
為了充分發揮關係型資料庫的作用——讓它真正的成為應用的一部分，而不僅僅是存放資料的庫房——必須從開始構建資料庫時，就深刻理解業務需求。隨著產品的演變，資料層也會發生變化。
24、重視不確定性
當你面臨2中選擇的時候應該仔細考慮設計中的不確定性。
迫於壓力，人們常常為了決策而決策。這時可以借鑑期權思想（指在**交易中，權利的受讓可以在將來的某個約定的時間，根據當時的情況決定是否行使權利，即推遲做決定時間），當你在不同的系統開發路線之間舉棋不定時，不要急於做出決策。推遲決策，直到掌握更詳實的資訊，以便做出更可靠的決策。但也別太遲，要趕在這些資訊失效前利用他們。
25、不要輕易放過不起眼的問題
問題出現時，雖然個別團隊成員會發現一些端倪，但往往由於大多數人認識不到其嚴重性，這些問題不是被忽略就是被擱置，知道變得難以解決。
注意造成的原因和哪些方法克服這些消極因素。
26、讓大家學會復用
有這樣一種觀點，認為設計優良的框架、細緻考慮並精巧實現的架構自然會被人們重複利用。
但也是在滿足下列條件下擦可能被復用：
大家都知道它的存在
大家知道如何使用它們
大家認識到利用已有資源好過自己動手
27、架構裡面沒有大寫「i"
英文單詞架構（architecture）裡面有字母」i"但不是大寫的「i」。它代表的不是那個喜歡喚起別人關注，喜歡凌駕於眾人之上的「i"(自我）。
自我可能是我們這最大的敵人。
如何避免犯錯誤？
需求不會撒謊。
重視團隊合作。
檢查你的工作。
自我反省。
28、使用」一千英呎高「的檢視
用來了解正在開發的軟體質量如何
在架構圖中，系統是由若干個小方框組成的，方框之間的連線代表著各種含義：
依賴關係、資料流、共享資源等。
這種圖好比從飛機上俯瞰地面上的風景，我們稱之為「三萬英呎高」的檢視。另一種典型的檢視是源**，好比佔在地面上看大地。兩種檢視都無法衝分鐘展現軟體的質量：前者太抽象，而後者細節太多，以至於我們看不清整個架構。很顯然我們需要乙個介於2著之間的檢視——「一千英呎高」的檢視。
"一千英呎高「的檢視提供的資訊來自恰當的層次，囊括大量資料和多鐘度量標準，例如方法數，類扇出數和圈複雜度。具體的檢視與特定的質量屬性密切相關。
一旦我們繪製出合適的檢視，判斷軟體質量就更客觀了。
29、先嘗試後決策
建立乙個應用需要作出很多決策。有些決策設計挑選框架和函式，而另一些則需要選定特定的設計模式。
架構師應該持續關注那些馬上要制定的決策，架構師可以在決策之前，要求幾個開發人員商量解決方案，比較不同解決方案的優點和弊端。
對同乙個問題嘗試2種或者2種以上的解決方案，可能是代價最低的選擇。事後發現方案不合適或者是沒人發現方案不合適都是糟糕的情況。
30、掌握業務領域知識
高水平的軟體架構師不僅要懂技術，還要掌握問題空間對應的業務領域的知識。缺乏業務領域知識的架構師不能順利地解決問題，無法把握業務目標和業務需求，也就難以設計有效的架構來滿足需求。
軟體架構師應該知道的97件事之概括1 15
架構師是一種神秘的職位，據說每個架構師都有密不可傳的方法，當然我們不信，更多的是只可意會不可言傳。就是說了我們也不會懂，因為還每到 火候 所能做的就是，當我們到這種火候的時候我們能想起來曾經有過架構師這麼說過，然後我們就可以更自信的向前大步走.1 客戶需求重於個人簡歷 積累一批滿意的客戶，選擇切合實...
軟體架構師應該知道的97件事 筆記 一
1.客戶需求重於個人簡歷 不要為了學習新的知識或豐富自己的簡歷而選擇新技術解決問題，要盡量選擇切合實際的技術解決客戶的難題。腳踏實地的為客戶著想，選擇正確的方案可以降低專案的壓力，團隊工作起來更開心，客戶也會更滿意，從而你也會有更充裕的時間學習新的知識。2.簡化根本複雜性，消除偶發複雜性 根本複雜性...
軟體架構師應該知道的97件事 筆記 四
46.避免重複 如果開發人員複製救命 中的內容，說明這部分還可以簡化，甚至全部提取出來。消滅複製是架構師的責任，如果有重複，則應該重新研究框架，創造更完善的抽象機制。47.歡迎來到現實世界 現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。如果現實世界帶來了...