架構漫談是由資深架構師王概凱 Kevin 執筆的系列專欄，專欄將會以 Kevin 的架構經驗為基礎，逐步討論什麼是架構、怎樣做好架構、軟體架構如何落地、如何寫好程式等問題。
什麼是架構？
根據要解決的問題，對目標系統的邊界進行界定。
並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。
並對這些切分出來的部分，設立溝通機制。
根據 3，使得這些部分之間能夠進行有機的聯絡，合併組裝成為一個整體，完成目標系統的所有工作。
為什麼會產生架構？
必須由人執行的工作（不需要人介入，就意味著不需要改造，也就不需要架構了）
每個人的能力有限（每個人都有自己的強項，個人的產出受限於最短板，並且由於人的結構限制，同時只能專注於做好一件事情，比如雖然有兩隻眼睛，但是隻能同時專注於一件事物，有兩隻手，無法同時做不同的事情。ps. 雖然有少部分人可以左手畫圓右手畫框，但是不是普遍現象）
每個人的時間有限（為了減少時間的投入，必然會導致把工作分解出去，給擅長於這些工作的角色來完成，見 2，從而縮短時間）
人對目標系統有更高的要求（如果滿足於現狀，也就不需要進行架構了）
目標系統的複雜性使得單個人完成這個系統，滿足條件 2，3（如果個人就可以完成系統的提高，也不需要別的人參與，也就不需要架構的涉及，只是工匠，並且一般這個工作對時間的要求也不迫切。當足夠熟練之後，也會有一定的架構思考，但考慮更多的是如何提高質量，提高個人的時間效率）
當這 5 個條件同時成立，一定會產生架構。從這個層面上來說，架構是人類發展過程中，由懵懵懂懂的，被動的去認識這個世界，變成主動的去認識，並以更高的效率去改造這個世界的方法。以下我們再拿建築來舉例加強一下理解。
如何做好架構之識別問題
我們先看一則笑話。女主人公：老公，把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半，然後下鍋。
當然很多人會說，這個是溝通問題，然後一笑了之。其實，出現這個現象是由於我們大部分時候過於關注解決問題，急於完成自己的工作，而不關心“真正的問題是什麼”而造成的。當我們去解決一個問題的時候，一定要先把問題搞清楚。這也是我為什麼要單獨寫一篇文章講這個的原因。去看看軟體開發工作者的時間分配也可以看出，大家大部分時間花在討論解決方案和實現的細節上，基本都不會花時間去想“問題是什麼”。或者即使想了一點點，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什麼的工程師，才可能會真正的成長為架構師
以這個笑話為例，看看在我們處理問題的時候，都會犯什麼樣的錯誤：
被告知要處理一個問題，但是交過來的實際上是一個解決方案，不是問題本身
被告知要處理一個問題，直接透過直覺就有了一個解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個合適
那麼如何識別問題呢?
所有的概念基本都有一個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。
架構師應該問的第一個正確的問題就是：目標問題是誰的問題。
當我們處理問題的時候，如果發現自己正在致力於把自己的工作完成，要馬上警惕起來，因為這樣下去會演變成沒有 ownership 的工作態度。在面對概念的時候，也會不求甚解，最終會導致沒有真正的理解概念。
作為軟體工程師或者架構師，我們大部分時候是要去解決別人的問題，“別人”是誰，是值得好好思考的。在這個故事裡面，男主人要解決的，實際上是這個家庭晚餐需要吃土豆的問題，目標問題的主體實際上是這個家庭的成員。
明白了問題的主體，這個主體就自然會帶來很多邊界約束，比如土豆是要吃的，要給人吃的，而且還是要給自己的家人吃的。“切土豆下鍋”這個問題，因為識別了問題的主體，自然而然的就附帶了這麼多的資訊。後續如何煮，是否放高壓鍋煮，放多少水，煮多長時間等等，就自然而然能夠問出來其他問題來了，說不定還能夠識別出來，女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題。可以想象，這樣下去最後的結果一定是大家都滿意的，因為真正的問題解決了。只有真正明白了是誰的問題，才能夠真正地完成自己的任務，真正地把自己的問題解決掉，而不是反過來。
由上面的分析可以看出，找出問題的主體，是做架構的首要問題。這也是我一再強調的，我們要解決的問題，一定都是人的問題。更進一步，架構師要解決的，基本都是別人的問題，不是自己的問題。再進一步，我們一定要明白，任何找上架構師的問題，絕對都不是真正的問題。為什麼呢? 因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。
如何做好架構之架構切分
架構的切分的導火索是人的負載太重。
架構的切分實際就是對 stakeholder 的利益進行切分或合併，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。
架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。
架構切分的結果一定是一個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。儘可能變成一顆平衡樹，才能讓整個系統的效率最大化。