編程即設計，代碼即架構。
概述###
架構，這個詞比較神秘，以致於很多程序員望而卻步，以為要什么了不得的本事。
架構的目標是什么呢？代碼，實現所需服務；架構，致力於以更小成本、更高質量地實現所需服務。架構，是兼顧質量與成本的魔法。 但架構並不研究如何實現具體服務，—— 它研究的是如何妥善安置那些實現服務的構件，管理依賴、邊界和變化。
-
如何將不變從變化中分離出來，沉淀為穩定的組件 ？如何管理組件之間的依賴 ？
-
如何識別組件所在的邊界和上下文？ 如何管理各種邊界和上下文 ？
-
如何讓變化更容易顯露和識別 ？ 如何管理多維度的變化 ？
-
如何讓業務邏輯變成可配置的易變更的插件 ？
目標###
小問題小設計，大問題大架構。架構聽上去高大上，實際上也是為了解決問題的。不過，架構與程序不同，是在不同層次上求解問題。
架構設計是宏觀性考量，在整體上理解問題的復雜性，給出方案，並論證方案的可行性，提供一系列准則指導執行。缺乏架構設計而直接着手處理問題，會出現三個嚴重問題：
-
在遇到實質性難題時，會一籌莫展或反復折騰，一次次返工，耗費大量的人力和成本；
-
缺乏質量的考量，上線后發現無法滿足用戶的需要；
-
缺乏整體的考慮，在業務發展的時候，原有實現不具擴展性，無法敏捷地支持中期和長遠目標。
因此，架構的目標主要有三個：
-
提前識別問題的復雜性和關注點，提供可行的經過論證的解決方案；
-
建立服務質量指標，確定設計方案可以滿足指定的質量指標；
-
規划整體設計，提供長遠的可擴展性。
要實現架構目標，先要問：要解決的問題是什么？問題的復雜性在哪里？弄清楚目標和靶點，才能一擊命中。
衡量###
一個好的架構設計，它起什么作用呢？
-
是不是有針對性地解決了問題固有的復雜性？ 通過提供漸進穩定的領域模型，讓問題理解、描述和求解都更清晰自然了；
-
是不是令需求更快地實現，大幅降低了開發成本？ 比如原來要花時間修改代碼、測試、發布系統，后續只要新增配置，測試並刷新配置就搞定了；原來需要5人日，現在只需要 2人時；
-
是不是讓系統的依賴更清晰了？比如原來你調我我調你，亂成一團，現在能夠清晰地看到數據流在各個模塊的流通和流向、脈絡；
-
是不是更穩定了？比如原來磕磕碰碰，做百次操作就有一次失敗，現在做十萬次操作才有一次失敗；
-
是不是更容易操作了？比如原來需要ABCDE五步操作，現在一鍵無憂完成；
-
是不是足夠有彈性和靈活性，可以支撐數年的業務發展？ 比如原來遇到新業務就要做許多兼容，現在只要配置一些規則、流程就能適應新業務的發展。對新增開放，對修改關閉。
綜上所述，架構設計至少有幾個方面可以衡量：
-
識別出問題的關鍵復雜性，建立穩定有效的領域模型。
-
大幅降低開發與維護成本。 可以落定到人力與時間。
-
系統脈絡更清晰。可以繪制出系統模塊的依賴圖，通過依賴圖的節點與節點鏈接數量來判斷。
-
更穩定。操作失敗、出現各種問題的比率。
-
更容易操作。 操作的步驟數 乘以 操作失敗的比率。
-
彈性和靈活性。 支持新業務的難度，以新增代碼量和修改代碼量來衡量。