在軟體開發領域，自從架構這個詞被廣泛傳播之後，產生的架構模式也非常多，架構關注點也在增加。但回到「道」的層面，架構的定義或者說本質還是：
架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。很多做業務功能的增刪改查開發感受到無趣的小夥伴常把做架構想象成一片樂土，沒有嘈雜的業務聲音干擾，可以專心做一番牛x的技術。會把架構單純的理解成，牛x的效能、牛x的tps、高可用，支撐了多少pv等等。但是其實這些只是架構很小的一部分，並不是全部。在網際網路時代之前都是c/s程式的天下，那個時候並沒有對效能等有像現在這樣的關注度，但是就已經有架構之說了。 世上本無架構，只是由於團隊越大越需要對整體的規則做約定，好讓大家往同乙個方向發力，避免各自為戰，產生大量的內耗，所以才逐漸形成了架構。這條路就是「世上本無路，只是因為走的人多了變成了路」。
為什麼說乙個軟體架構是很重要的呢？當我們的團隊人數只有2、3個人，甚至只有1個人單槍匹馬的情況下，可能架構凸顯的作用不是那麼的明顯，但是如果團隊大了之後相信下面的這些現象會比較常見：
任何事物都是有兩面性的，並不是說上面的這些問題，我們通過架構就要往另外乙個極端去走。比如在大型的分布式系統中，不同子程式的確有必要在某些時刻選擇同型別的其它中介軟體。如kafka和rabbitmq雖都是mq，但在特定的場景下能發揮的價值是無法相互替代的。
所以我們做架構有一點也是比較重要的，就是去balance，選擇乙個投入產出比最優的方案。關於這點第四段中會多說幾句。
除此之外，架構的主要目的是為了讓大家往同乙個方向，在同乙個標準之上去發散擴張。一是把控硬性的下限標準，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發展空間。好比造一幢大樓，把框架結構設計好搭好，讓大家形成乙個共識，什麼是承重牆不能破壞，什麼是創變空間可以自定義。在這樣的基礎下各自發展。這個看上去是個限制，但卻是做架構最重要的任務，所謂再多的文件，再多的最佳實踐都比不上一條約束。降低複雜度、降低理解難度，是實實在在的收益。最怕的就是憑空假設帶來的過度浪費。
更甚之，我們做架構追求的理想國度是乙個大家擁有一致共識的世界，架構是大家都像吃飯喝水這樣習以為常的習慣。去理解或者接手其它人負責的專案的時候就好像是自己寫的一樣。這個時候就消滅架構了，就好比現在沒有人會教你如何吃飯一樣。（就當yy一下吧：）
上面提到更多的是做架構的目的，那麼要做好架構，主要就是要做好抽象，做抽象的方式是模擬，做模擬的方式可以使用用例圖。所以建議大家多畫圖，通過畫圖來將大腦中抽象的結果直觀的體現在前面，再來進一步分析合理性。主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：
另外一種是魯棒圖，如圖：
整個過程的主要目的是：
理想的世界裡，我們程式的邊界設計恰好匹配於業務邊界。然而我們作為工程師首先要承擔業務需求的壓力，只能擠時間去做這些非業務性工作。也因此老專案的業務邊界也並不總是如新專案那樣明晰。
這意味著做任何架構的改動要考慮優先順序，特別在拆分業務領域之前認真地思考業務的邊界。排定優先順序，考量拆分的收益與風險。劃分業務的邊界，則需要更多的思考拆分後的未來將如何溝通協作，然後再考慮技術因素。在技術因素前，主要考量這幾點：
上面這些完成了之後，便是選擇合適的中介軟體、技術框架來滿足技術層面的要求，這個的選拔主要以下面幾點來考量：
上面提到的這些關注點都是架構師的職責，另外特別重要的一點是，架構師必須要是個有追求的「好碼農」！！！（劃重點）。軟體架構師不像建築師，其面對的本身是乙個抽象的事物，如果再脫離了實操，這基本和紙上談兵無異。所以實際工作中的難點、要點都得清楚，並且能夠給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本
成為了乙個真正的「好碼農」就向架構師邁出第一步了。而後呢，需要不斷以深 –> 廣 –> 深 –> 廣的節奏去開疆擴土，擴大自己的知識領域，當然需要以貼近當前工作內容的知識為主，這是第二步。到了這還沒完，還有打造三板斧：業務能力、溝通能力、個人魅力。
題外話，在國內，純技術的架構師沒有應用型的架構師吃的開。所以此文皆以應用型架構師的職能要求為參考。
回到文章開頭，架構的表現形式有很多，從本質上單體應用的架構設計思想和分布式系統是一致的，所謂服務化其實也是模組化的思想，只是維度的不同，導致用到的一些工具或者環境不同，但這都是「術」層面的東西。光學這些招數，永遠也學不完。架構之路漫長，繼續前行，共勉。
如何進行軟體架構設計3 如何成為架構師
架構師是具有技術發言權，方向決策權，和團隊人員開發資源調配權的開發團隊的teamlear，也是這個程式的設計者，當然他是這個程式團隊的靈魂！因此，不想當teamleader的程式設計師，絕對不可能成為真正意義上的架構師！同時，不是teamleader的架構師，也是乙個被架空的，蒼白無力的架構師！架構...
為什麼要做架構設計
架構設計的目標 減少重複 重複是萬惡之源！這是從結構化程式設計時代就存在的格言，在物件導向時代依然是金玉良言。方便理解邏輯 清晰簡潔的結構能夠讓人以最快的速度理解和掌握程式 的邏輯，因此也就便於維護和擴充套件。適應需求變化 因此有了各種設計模式，大多都是針對某種需求發生變化的可能性而提出。便於分工協...
如何做好架構設計與寫好架構設計的文件？
1 建議讀一下ieee1471 2 一下是我的寫文件的一些心得 現代架構設計文件的編寫 4 1 檢視與 uml 軟體架構設計已經逐漸成為現代軟體開發過程的核心，然而能夠清晰表明架構設計並不是一件容易的事，就物件導向開發而言，rup 的 4 1 檢視已在架構設計的撰寫中得到了廣泛的應用和認可。對於 4...