架構設計三原則
合適原則
合適原則宣言：合適優於業界領先
失敗原因
沒那麼多積累，卻想一步登天，是失敗的第二個主要原因
沒那麼卓越的業務場景，卻幻想靈光一閃成爲天才，是失敗的第三個主要原因
沒那麼多人，卻想幹那麼多活，是失敗的第一個原因
簡單原則
簡單原則宣言：簡單優於複雜
軟件領域的複雜性
結構的複雜性
組成複雜系統的組件數量更多
這些組件之間的關係也更加複雜
組件越多，就越有可能其中某個組件出現故障
某個組件改動，會影響關聯的所有組件
定位一個複雜系統中的問題更加困難
邏輯複雜性
單個組件承擔了太多功能，邏輯複雜幾乎會導致軟件工程的每個環節都有問題
問題：
代碼很龐大，一次clone時間很長
幾十上百人維護一套代碼，不小心改了一行 代碼，導致征戰崩潰；需要不停討論版本計劃、協調資源、解決衝突
需求過多導致分支過多，各種分支合併和覆蓋，每天上線幾十個版本
線上出現故障，需要幾十個人一起定位和處理
功能複雜的組件的一個典型特徵就是採用了複雜的算法。複雜的算法導致問題難以理解，進而導致難以實現和修改，並難以快速解決問題
演化原則
演化原則宣言：演化優於一步到位
對於軟件來說，變化纔是主題；本質是：軟件架構需要根據業務發展不斷變化
設計過程
首先，設計出來的架構要滿足當時的業務需要
其次，架構要不斷地在時間應用過程中迭代、保留優秀的設計、修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使得架構逐漸完善
第三，當業務發生變化時，架構要擴展、重構、甚至重寫；代碼也會重寫，但有價值的經驗、教訓、邏輯、設計等卻可以在新架構中延續