《架構漫談》是由資深架構師王概凱執筆的系列專欄，專欄以王概凱的架構經驗為基礎，逐步與我們討論了什麼是架構、怎樣做好架構、軟體架構如何落地、如何寫好程式等問題。
全系列共有九部分：
（1）什麼是架構：
首先把架構的概念討論明白，然後在對架構進行分析才顯得清晰有意義。架構是人類發展過程中，由被動地去認識這個世界，變成主動的去認識，並以更高的效率去改造這個世界的方法。由不同角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為一個整體，並完成這個整體所需要的所有活動，就是架構。一切都是為了滿足人的越來越高的需求，提升質量，減少時間，提高效率，並且讓程式碼之間更加有機的進行溝通。
架構這個詞在軟體工程很早之前就已經出現了，在人類的早起大家的衣食住行都靠自己，不需要合作，這時候自然不需要架構。但是經過一段發展，人類發現合作的力量是巨大的，每個人都有自己所擅長的部分，在進行分工合作的時候產生的結果往往大於個人，這時候就產生了社會的架構。
從中可以看出架構產生的動力有五個：
1、由人執行；
2、每個人能力有限；
3、每個人時間有限；
4、目標期望高；
5、目標複雜。
對於架構的理解，大致總結如下：
1、根據要解決的問題，對目標系統的邊界進行界定。
2、對目標系統按某個原則的進行切分，切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。
3、對這些切分出來的部分，設立溝通機制。
4、使得這些部分之間能夠進行有機的聯絡，合併組裝成為一個整體，完成目標系統的所有工作。
而架構的產出物，自然就是對問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合併的原則以及理由，以及拆分，拆分出來的各個部分和合並所對應的角色和所需要的核心能力等。
（2）認識概念是理解架構的基礎：
架構實際上解決的是人的問題，而概念是人認識這個世界的基礎，自然概念的認識就非常的重要。
在做架構師的群體中，不談抽象好像就不是一個合格的架構師。抽象這個詞代表的含義，實際上是把不同的概念的相似的部分合並在一起，形成一個新的概念。這個裡面問題很多：首先“相似的部分”在不同的人看來，並不一定那麼相似；其次，抽象之後形成的是一個新的概念，和原來那個概念並不一樣，所解決的問題也不一樣。所以我們不能用抽象來定義一個事物，抽象實際上是一個分類的過程，完全是另一碼事。
理解概念，對於理解這件事物來說十分重要。所以理解概念的背後用途，才能更好的解決問題。
根據架構的定義，要做好架構所首先必須具備的能力，就是能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。之所以強調這個，是因為做架構的時候，很多時候都是在一個新的領域解決問題，必須要快速進入並掌握這個領域，然後才能夠正確的解決問題。
（3）如何做好架構之識別問題：
做好架構首先需要做的就是：識別出需要解決的問題。
一般來說，如果把真正的問題找到，那麼問題就已經解決了 80% 了，這個能力基本上就決定了架構師的水平。
如何去識別問題呢？所有的概念基本都有一個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。作為軟體工程師或者架構師，我們大部分時候是要去解決別人的問題，“別人”是誰，是值得好好思考的。明白了問題的主體，這個主體就自然會帶來很多邊界約束。而從問題暴露的點，一點點去溯源查詢，一定會找出來誰的問題，以及是什麼問題。
我們要解決的問題不僅僅是表面上的工作，架構師需要完成的是隱藏的使用者實際需要解決的問題。最主要的兩個問題就是：1、這是誰的問題？ 2、有什麼問題？架構師的主要任務大部分在於問題一上。
（4）如何做好架構之架構切分：
很多時候問題的產生都是因為溝通的誤解，或者主觀上有很多不必要的利益訴求導致的，但是總還有一部分確實是有問題的，需要做調整，那麼就必須要有所動作，做相應的調整。
這個調整，就是架構的切分，所有的切分調整，都是對相關人的利益的調整。為什麼這麼說呢，因為維護自己的利益，是每個人的本性，是在骨子裡面的，我們不能逃避這一點。
切分也需要有原則，這四個原則是：
1、連續時間內的活動不能切分；
2、權利義務對等；
3、不超出一個人的負載；
4、對外部透明。
關於架構切分總結如下：
1、架構的切分的導火索是人的負載太重。
2、架構的切分實際就是對 stakeholder 的利益進行切分或合併，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。
3、架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。
4、架構切分的結果一定是一個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。儘可能變成一顆平衡樹，才能讓整個系統的效率最大化。
（5）什麼是軟體：
軟體的歷史，實際上可以說是用機器模擬人的歷史。在初期，軟體使用二進位制編寫的，從硬體到軟體，成本都非常的高。隨著半導體技術的進步，硬體的成本越來越低，效能越來越高，甚至出現了摩爾定律：當價格不變時，積體電路上可容納的元器件數目，約每隔 18-24 個月增加一倍，效能提升一倍。
軟體工程師慢慢越來越多，開發軟體的成本也越來越低。因此，人們越來越願意把原來只有人才能做的事情，交給計算機來做。結果就導致軟體越來越豐富，能夠做的事情也越來越多，成本也越來越低。隨著軟體的規模的變大，做好一個軟體也變得越來越難了。有些程式設計師熟練了之後，提高了自己的生產力，並發現還可以幫助別人寫程式，慢慢軟體就變成了一個獨立的行業。
程式從早期由一個人完成，也逐漸變成了由很多不同角色的人共同合作來完成。
一開始是懵懵懂懂的去寫軟體，後來慢慢的就有意識的去切分，演變成了不同的架構。這個背後的動力也是一樣的，就是提升參與的人的利益，降低成本。導火索也是軟體工程師的任務太重，我們需要把很多工作拆分出來。拆分的原則也是一樣的，如何讓權責一致。所以軟體開發就開始有分工了，行業知識和業務的識別。
軟體的本質，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產力，提升人類自己的利益。
（6）架構要解決什麼問題：
業務問題，計算機問題。
有兩種架構：
1、軟體因為流量增大而分拆成不同的執行單元，在機器上部署所形成的架構，屬於軟體架構。
2、每個執行單元為了讓不同角色的人，比如前端，業務，資料儲存等能夠並行工作，所分成的程式碼架構，也屬於軟體架構。
（7）不要空設架構師這個職位，給他實權：
架構師必須是一個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。
如果一個人在工作中，只是致力於完成自己的工作，以做好自己的工作為主要目標，那麼最多隻能成為一個工匠，無法成為一個架構師。因為這個過程解決的還是自己的問題，並沒有時間的壓力，可以隨意什麼時候做完都可以。要成為架構師，必須要超越這個恐懼才能夠看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因為僅僅是完成了自己的工作，也並不一定就解決了別人的問題。如果別人的問題沒有解決 -- 即使我們認為自己的工作完成了 -- 我們的工作實際也沒完成，因為我們工作是否完成，是別人說的算的，不是我們自己。
架構師是要去平衡別人的利益，甚至會調整別人的利益的。
（8）從架構的角度看如何寫好程式碼：
當我們有了好的架構，那就需要考慮如何將架構落地，千萬不要讓程式碼成為架構擴充套件的瓶頸，儘量降低架構分拆的成本。
軟體實際上是對現實生活的模擬，虛擬化。這是一個非常重要的前提，結合每個部署單元所承擔的責任，可以明確的拆分為兩個不同的責任：
1、表達業務邏輯的程式碼。
2、對使用者提供訪問並儲存業務邏輯執行結果的程式碼。
業務邏輯：在軟體程式碼中，不需縮排和計算的順序呼叫，包括縮排的程式碼目的是 catch exception 的，都不算邏輯，除此以外都是邏輯。
（9）理清技術、業務和架構的關係：
技術：通過人為創造條件，讓指定的規律按照人類的意願發生，這就是技術。
技術與架構，以及與業務之間的關係：技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。所以：
1、技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。
2、有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求—— 也就是業務。
3、在解決同一個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術，這是人類利益訴求所決定的。
4、一般剛開始解決根本問題的技術的效率是比較低的，只是把不可能變成了可能。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被自己或他人加以改進，這部分就會形成新的技術。
為什麼技術人員總是和業務人員發生衝突呢？ 這是因為技術人員很多時候關心的技術，和業務的主要目標往往不是直接對應的。只有直接解決業務問題的那個和業務直接相關的技術，即是樹的根節點，才能解決問題。
架構師應該承擔起解決業務問題的這個角色來，準確識別採用什麼技術的能力，考慮的主要因素也是長期的成本和收益，讓技術人員致力於為業務在計算機中跑起來而努力。
只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到一個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。