03 架構設計三原則

本文是通過學習李運華老師的《從0開始學架構》課程的隨筆

現在自己對架構雲裡霧裡的感覺，結合工作中的實踐，學習與總結，慢慢的，會有質的提公升的。

將軍難打無兵之戰

羅馬不是一天建成的

冰山下面才是關鍵

在專案管理中，專案啟動、規劃、執行、監控、驗收的整個過程，我們需要整個過程中合理評估和知曉我們所擁有的資源，人力、物力、財力等資源，知曉並合理安排使用，那麼輸入和產出比應該是在可控範圍內，風險也應該盡可能的會在可預知風險中。

架構設計也是如此，如今技術發展很快，各種架構框架層出不窮，不一定先進的就是我們應該選擇的，不是全而大的就是我們團隊需要的。

架構是需要資源支撐的(我們需要考慮人力、物力、財力等)；架構是需要不斷實踐趟坑的，穩紮穩打通過實踐不斷積累演進；架構是需要業務支援的（量變會引起質變），當業務不斷增長時，它會逼著你去做架構的調整及演化。

「複雜」在製造領域代表先進，在建築領域代表領先，但在軟體領域代表「問題」

複雜度的體現：

1、結構複雜性

(1)、2個、3個、n個元件，元件越多，就越有可能某個元件故障從而導致系統故障；

(2)、某個元件的改動，會影響關聯的所有元件；

(3)、定位乙個複雜系統中的問題總是比簡單系統更加困難；

2、邏輯複雜性

單個元件承擔了太多的功能

邏輯複雜度會導致軟體工程的每個環節都有問題，如迭代、分支……。

軟體設計產出投入使用後，需要不斷的迭代變更(新需求等)、需要不斷的修改。

如果簡單的方案和複雜的方案都可以滿足需求，最好選擇簡單的方案。

對於建築來說，永恆是主題，對於軟體來說，變化是主題。

軟體架構需要根據業務發展不斷變化。軟體架構設計類似於大自然設計乙個生物，通過演化讓生物適應環境，逐步變得更加強大。

起初設計出來需要滿足當時的業務需要→需要不斷在世紀應用過程中迭代，保留優秀的設計，修復不足和缺陷，改正錯誤的設計、去除無用的設計→業務發生變化時，需要對架構進行擴充套件、重構甚至重寫，但有價值的經驗教訓、邏輯設計等卻可以在新架構彙總延續。