成為架構師是每個程式設計師的夢想，但是程式設計師和架構師之間有乙個巨大的鴻溝，需要程式設計師去跨域方能成為架構師，那就是「不確認性」。
對於程式設計而言，其結果是確定的，但是對於架構是不確定的。架構沒有程式設計那麼的的約束，可以使用這種方式去實現，而對各種選擇，我們就容易迷茫，到底是選擇業務最先進的技術，還是開源、商業的…,面對各種選擇，架構師可以遵循下面三個原則來做出選擇，那就是：
合適原則的宣言:"合適優於業界領先"
簡單原則的宣言：簡單優於複雜
軟體架構的一門技術活，很多人都會把軟體架構與傳統的建築做對比，它們二者間有很多的相似之處。但是它們有很大的區別，建築追求的是不變，可以追求複雜，而軟體追求的是變。建築建好以後，幾十年上百年都可能不會發生改變，但是軟體的話，會跟著需求不段的發生變化。複雜在建築領域代表的是先進，但是在軟體領域代表的則是問題。
軟體領域的複雜主要體現在下面幾個方面：
邏輯複雜性
意識到結構複雜性後，我們的第一反應就是減小元件，但是減小元件會有另外乙個問題，那就是元件邏輯複雜。假如我們把電商的所有模組(登入、註冊、購物車、商品、支付、訂單)放在乙個元件，那就是典型的邏輯複雜性。
把這些放在一起會有什麼樣的問題呢？
不用多想，出現這樣的問題，每個人都會受不了。
功能複雜的另乙個特點，就是演算法複雜。演算法複雜的乙個問題就是定位問題困難。
無論是結構複雜還是邏輯複雜，都會改系統帶來很大問題，所有在做架構時，在有複雜方案和簡單方案可以選擇時，盡量選擇簡單方案。
演化原則的原則是：演化優於一步到位。
上文提到過，建築是不變的，而軟體是不斷變的。我們不可能在現在就設計出十年後的系統，就像window作業系統不可能一開始就做出win10來，而是從win1.0慢慢演化而來的。
軟體架構的設計應該遵循乙個這樣的規律：
注：文章內容總結於極客時間08 | 架構設計三原則
03 架構設計三原則
本文是通過學習李運華老師的 從0開始學架構 課程的隨筆 現在自己對架構雲裡霧裡的感覺，結合工作中的實踐，學習與總結，慢慢的，會有質的提公升的。將軍難打無兵之戰 羅馬不是一天建成的 冰山下面才是關鍵 在專案管理中，專案啟動 規劃 執行 監控 驗收的整個過程，我們需要整個過程中合理評估和知曉我們所擁有的...
架構設計三原則
架構設計三原則 合適原則 合適原則宣言 合適優於業界領先 失敗原因 沒那麼多積累，卻想一步登天，是失敗的第二個主要原因 沒那麼卓越的業務場景，卻幻想靈光一閃成為天才，是失敗的第三個主要原因 沒那麼多人，卻想幹那麼多活，是失敗的第乙個原因 簡單原則 簡單原則宣言 簡單優於複雜 軟體領域的複雜性 結構的...
架構設計三原則
成為架構師，可以說是絕大多數開發者的夢想。但是這個過程並不是一件簡單的事情，如果簡單的話，意味著供過於求，就代表著不值錢了。在目前國內，架構師也算是乙個比較吃香的職業。對於年齡較大的小夥伴們，他們的選擇通常有這麼幾個?第一 繼續開發者之路，畢竟現在30多歲的資深工程師也不少 通常這些人，對於公司來說...