《聊聊架構》結束前，要不要再聽聽它的故事？

《聊聊架構》近期將從極客商城下架。自去年在極客商城獨家銷售以來，《聊聊架構》已經陪伴大家 10 個月之久。從第一周銷量就突破 3000 本到後續收到無數讀者的書評，用戶的每一點反饋我們都倍感珍惜。年後我們又加印了 1000 本，希望這本書最後能給您帶來一些收穫。

在軟體行業，架構師和工程師就類似於上帝，創建出形形色色的軟體產品來服務於人類。要想當好這個角色，架構師自然也需要具備某種上帝的視角，來觀察並表達這個世界。

《聊聊架構》以作者的架構經驗為基礎，逐步討論什麼是架構、怎樣做好架構、軟體架構如何落地、如何寫好程序等問題，幫你理清技術、業務和架構之間的關係，洞見架構之道，進階為更優秀的架構師。

什麼是架構？

架構實際上解決的是人的問題，架構的產出物就是對問題的分析，以及解決問題的方案。它包括：拆分的原則以及理由，溝通合併的原則以及理由，以及拆分，拆分出來的各個部分和合併所對應的角色和所需要的核心能力等。

根據要解決的問題，對目標系統的邊界進行界定。

對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或串列開展工作，一般並行才能減少時間。並對這些切分出來的部分，設立溝通機制。

根據 2，使得這些部分之間能夠進行有機的聯繫，合併組裝成為一個整體，完成目標系統的所有工作。

這就是架構。

認識概念是理解架構的基礎

要做好架構首先必須具備的能力是能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題。

比如，什麼是「杯子」？杯子這個概念並不是瓷器，回歸作用：其實是為了解決「人需要一個可單手持握，但是希望避免直接接觸所盛物體」這個問題。

每個概念實際上所解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了一個名字，這個名字就是對應的某個特定的概念。

事實上，這一能力，在任何一個領域都是適用的。比如我們如果想要學習一項新的技術，如 Hibernate、Spring、PhotoShop、WWW、Internet 等等，如果知道這些概念所要解決的問題，學習這些新的技術或者概念就會如虎添翼，快速的入手；學習一個新的領域，也會非常的快速有效；使用這些概念來解釋問題，甚至發明新的概念都是很容易的事。

為什麼強調這個？因為做架構的時候，很多時候都是在一個新的領域解決問題，必須要快速進入並掌握這個領域，然後才能夠正確的解決問題。

如何做好架構？

識別問題，找到問題的主體

如果把真正的問題找到，那麼問題就已經解決了 80% 了。這個能力基本上就決定了架構師的水平。

找出問題的主體，是做架構的首要問題。這也是前面強調的，我們要解決的問題，一定都是人的問題。

更進一步，作為軟體工程師或者架構師，我們大部分時候是要去解決別人的問題，「別人」是誰，是值得好好思考的。

再進一步，我們一定要明白，任何找上架構師的問題，絕對都不是真正的問題。為什麼呢? 因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。

一般來說，從問題暴露的點，一點點去溯源查找，一定會找出來誰的問題，以及是什麼問題。最壞情況就是當我們時間或者能力有限，實在是無法定位出是誰的問題的時候，比如系統出故障，也就意味著我們無法根本解決問題。這時最好的辦法就是去降低問題發生所帶來的成本，盡量去隔離問題影響的範圍。給我留出時間和空間去識別真正的問題。

總結一下，要正確的認識問題，需要問兩個問題：

這是誰的問題？

有什麼問題？

當得到的回答是支支吾吾的時候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經驗，問題 1 會花比較多的時間，也是支支吾吾最多的地方，因為架構要解決的問題都是人的問題。但是一旦確定了答案，問題 2 就會變得非常容易。可以這樣說，架構師的能力大部分會體現在問題 1 的識別上。

架構切分，本質上是利益的調整

在識別出是誰的問題之後，會發現，在大部分情況下，問題都迎刃而解，不需要做額外的動作。但總還有一部分確實是有問題的，需要做調整，那麼就必須要有所動作，做相應的調整。

這個調整就是架構的切分。簡單來說：

架構的切分的導火索是人的負載太重。

架構的切分實際就是對 stakeholder 的利益進行切分或合併，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。

架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。

架構切分的結果一定是一個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。儘可能變成一顆平衡樹，才能讓整個系統的效率最大化。

什麼是軟體？

軟體的歷史，實際上可以說是用機器模擬人的歷史。不管大家有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。人們越來越願意把原來只有人才能做的事情，交給計算機來做。結果就導致軟體越來越豐富，能夠做的事情也越來越多，成本也越來越低。

所以，軟體的本質，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產力，提升人類自己的利益。

隨著軟體的規模的變大，程序從早期由一個人完成，也逐漸變成了由很多不同角色的人共同合作來完成。軟體工程師的職責在這個浪潮中，不堪重負，自然而然就分拆為不同的角色，形成了一個獨特的架構體系。這一切的背後，仍然是為了提升人類自己的利益，解決人類自己的問題。

軟體架構到底是要解決什麼問題？

如前所述，軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中運行起來的。要做到這一點需要解決兩個問題：

業務問題

具體的現實生活狀態下，沒有軟體的時候，所解決的問題的主體是誰，解決的是什麼問題，是如何解決，如何運作的？

計算機問題

如何把現實生活用軟體來模擬？模擬出來的軟體，需要哪些硬體設施才能夠滿足要求？ 並且當訪問量越來越大的時候，軟體能否支持硬體慢慢長大，性能線性擴展？因為硬體是可能會失效的，軟體如何在硬體失效的情況下，仍然能夠保證可用性，讓用戶能夠不中斷的訪問軟體提供的服務？怎麼收集軟體產生的數據，為下一階段的工作提供依據？

總之，軟體架構包括了：代碼架構，以及承載代碼運行的硬體部署架構。實際上，硬體部署架構最終還是由代碼的架構來決定。

架構師沒有話語權，還架什麼構！

架構師必須是一個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。

如果架構師只能夠通過建立某些流程來行使架構師的權利，比如強制架構 review，反而會造成很多內部不必要的衝突，最終都會導致這些流程流於形式，得不償失。

反過來，具備架構師能力的組織領導人，一定是一個很好的領導，這個組織一定是很健康向上的，因為每個人的權利和義務就是比較均等的。並且這類領導對於組織成員權利和義務的對等狀況會非常的敏感，會及時的調整組織架構，在問題發生之前就解決了。

這樣這個組織就會具備更好的抗壓能力，能夠更好的為這個組織的客戶服務，這個組織的成員內心一定都是比較平衡的，每個人的能力都能夠得到比較好的發展。

所有架構的核心就是組織架構。或者也可以這樣說，一個合格的組織領導人，一定必須是一個合格的架構師。

從架構的角度看如何寫好代碼

我們經常會聽說，重寫代碼，推翻原有架構，重新設計等等說法，來說明架構的進化。這實際上就是當初為了完成任務，沒有充分思考所帶來的後果。

工程師要想真正快速的完成代碼工作，就要克服自己對時間的恐懼，真正的去研究業務的問題，相關 stakeholder 的利益，把這個變成我們的習慣。寫代碼的時候讓該出現邏輯的地方出現邏輯，讓不該出現的地方不能出現。一旦不該出現的地方出現了邏輯，那麼要馬上意識到，這個地方是一個坑，這個問題一定和業務的分析不透徹有關係。

這裡還有作者分析的案例和圖示，請看書細細品味吧。

所以，你理清技術、業務和架構之間的關係了嗎？

技術人普遍看不起業務，認為技術更高端，而業務太低端，並且業務往往喜歡給技術挖坑。業務則覺得技術眼光高卻實際解決不了問題，而且常常理解有偏差，但是業務又無可奈何，因為自己不會。

為什麼會發生這種衝突呢？

這是因為技術人員很多時候關心的技術，和業務的主要目標往往不是直接對應的；業務也是負責某一部分的業務，也不是和業務的主要目標直接對應的，都是樹的分支節點。只有直接解決業務問題的那個技術（或業務）–樹的根節點–會和業務直接相關。所以一旦產生衝突，一般必須兩個根節點（一般都是領導）碰面才能解決問題，就是這個原因–他們都知道業務主要目標。

這也是為什麼下層無法理解上層，而上層都喜歡下軍令狀，要求下層執行。人只有盡量去理解上層的問題才能做下層的分拆。

在軟體行業，這個根節點技術就是軟體。這也是為什麼架構師要認識什麼叫軟體，軟體解決誰的問題，什麼問題，軟體本身又是怎麼分拆的，才能夠更好的組合不同的技術，完成業務的目標。而軟體裡面和業務直接相關的，只有 Business Domain 這一部分。

用人來打比方，Business Domain 相當於人的大腦，而 Service，Repository，Glue Code 等部分所採用的技術，全部都是計算機自己領域的技術，都是為了能夠讓程序跑起來，相當於人的四肢。

我們大部分開發人員的工作主要專註於四肢部分。我們真正應該投入的是大腦部分。因為大腦能夠決定四肢長什麼樣，而不是反過來。很多架構師、技術人員主要專註於計算機相關的技術，忽略了業務本身，甚至看不起業務，這也是為什麼技術總是和業務衝突的原因。

架構師應該承擔起解決業務問題的這個角色，專註於 Business Domain 和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。

只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到一個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！