最近看完了王概凱寫的九篇架構漫談後，對於軟體架構師是如何工作的，首先我們的先知道什麼是架構，架構就是根據要解決的問題，對目標系統的邊界進行界定，並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間，並且並對這些切分出來的部分，設立溝通機制，使得這些部分之間能夠進行有機的聯絡，合併組裝成為乙個整體，完成目標系統的所有工作。
軟體架構師想要做好架構，搜先需要的必備的能力九世紀正確的認識概念，能夠發現概念背後所代表的問，進而才能夠認識目標領域索需要解決的問題，這樣才能為做好架構打好基礎。
其次做好架構首先需要識別出需要解決的問題，這個能力基本上決定了架構師的水平。一般來說，如果把真正的問題找到，那麼問題就已經解決了 80% 了，要正確的認識問題，需要問兩個問題：1這是誰的問題？2有什麼問題？只要確定了問題一那麼問題二解答就會變得非常容易，架構師的能力大部分會體現在問題 1 的識別上。其次還有做好架構的切分，架構的切分的導火索是人的負載太重。架構的切分實際就是對 stakeholder 的利益進行切分或合併，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。架構切分的結果一定是乙個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。盡可能變成一顆平衡樹，才能讓整個系統的效率最大化。
軟體架構師是對軟體進行架構，那麼什麼是軟體呢，軟體是用機器模擬人，在硬體上編寫出的程式，就是軟體。軟體工程師是實現這個模擬過程的關鍵人物，他必須先理解人是怎麼在日常生活中完成工作的，才能夠很好的把這些工作在計算機中模擬出來，為了提公升人類自己的利益，解決人類自己的問題。
軟體架構實際上包括了：**架構，以及承載**執行的硬體部署架構。實際上，硬體部署架構最終還是由**的架構來決定。因為**架構不合理，是無法把乙個執行單元分拆出多個來的，那麼硬體架構能分拆的就非常的有限，整個系統最終很難長的更大。我們真正想快速的完成**工作，就要克服自己對時間的恐懼，真正的去研究業務的問題，相關 stakeholder 的利益，把這個變成我們的習慣。寫**的時候讓該出現邏輯的地方出現邏輯，讓不該出現的地方不能出現。一旦不該出現的地方出現了邏輯，那麼要馬上意識到，這個地方是乙個坑，這個問題一定和業務的分析不透徹有關係。
最後我們要理清技術，業務和架構的關係，技術總是在人類解決對業務的要求不斷提高的情況下產生，技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。所以：
技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。
有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求 -- 也就是業務。有人會問，不用鑽木取火了，但是弓弦加速轉動木棍還可以用啊？ 沒錯，因為弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業務問題。
所以技術與技術之間，有兩種關係：
在解決同乙個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。
一般剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業務的 enabler）。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發明人自己）加以改進，這部分就會形成新的技術。
當關係 2 發生的時候，這個地方必定會形成乙個切分，新技術會通過某種方式和原有的技術連線在一起形成乙個整體，讓這個新的技術可以和原有技術共同工作，使得原有的技術可以用更高的效率解決問題。因為要解決的主要問題（生火）並沒有發生改變，分拆所形成的是乙個樹狀的結構。
按照前面的架構定義，這個時候其實已經產生了架構。也就是說，一般是先有技術，才會有架構。這些其他技術（弓弦拉動木棍），是從直接解決問題的初始主要技術中分拆出來形成的，並通過樹狀結構和主要技術（鑽木取火）組合在一起。在解決主要問題（生火）之後，再開始逐漸的分拆為更為細粒度的技術（弓弦轉木棍）。
而這個細粒度的技術（弓弦轉動木棍）往往不會和業務的主要目標（生火）發生直接的關係。不同的技術，通過樹狀結構，組合在一起，形成了乙個完整的架構解決方案，共同完成業務的目標。這就是技術，業務和架構之間的關係。很多人把這個過程稱為架構的進化，我更願意把這個過程稱為技術的進步所導致的新的架構分拆，因為這個過程內在的動力，更多的是來自技術對解決業務問題的解決。
當技術所解決的問題和分拆出來要解決的問題，完全匹配的時候，這是最完美的。比如需要提供 web 要訪問的 service，很多 mvc 的 framework 就可以很好的滿足這一點。而這個時候如果非要自己實現乙個，很有可能就是重新發明輪子。
當技術所提供的能力遠遠超過需要解決的問題時，往往掌握技術和維護技術會成為瓶頸。因為越複雜的技術，成本越高。如果自己實現乙個僅僅是解決當前問題的方案，可能成本反而更低。這也是為什麼很多大型的網際網路公司不斷地開源出來自己的技術的原因。而這些技術對於我們來說是否適用？他們原本是用來解決誰的問題的？什麼問題？如果不清楚這些，就冒然採用，可能會導致更高的成本。
當技術所提供的能力和我們所要解決的問題部分匹配時，還是要看成本。比如當我們需要乙個錘子的時候，手邊正好沒有，但是卻有乙隻高跟鞋，勉強也可以替代錘子。但是長期來看，這麼用不划算，因為高跟鞋的**比錘子高很多，耐用性差很多，維護成本也高很多。
目的也是為了獲取更大更好的利益，準確識別採用什麼技術的能力，也是架構師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。
軟體架構師如何工作
通過閱讀構架漫談，軟體架構師工作需要了解一下幾個方面 首先要理解什麼是架構，為什麼需要架構 架構是規劃 設計和建造建築物和其他物理結構的過程和產物。人們完成一項任務，因為每個人的能力不同，所擅長的方向不同，所以如果自己去完成一項任務一般要花費很長的時間，效率很低，但是人們對目標有更高的要求，所以需要...
軟體架構師如何工作
要理解軟體架構師如何工作，在閱讀了架構漫談九篇部落格後，不妨先來看看架構是什麼。內容如下 1.根據要解決的問題，對目標系統的邊界進行界定。2.並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。3.並對這些切分出來的部分，設立溝...
軟體架構師如何工作
軟體架構師如何工作 閱讀了王概凱老師的架構漫談九篇部落格，從中了解到了什麼是架構 什麼是軟體架構師以及軟體架構師應如何工作。軟體架構師首先要搞明白問題的主體，之後把問題進行拆分形成架構，是工作人員的效率更高。架構師還必須要明白，所給出的解決方案 架構的分拆 合併方案，只有讓問題的主體的權責對等，才能...