架構(gòu)漫談（一）：什么是架構(gòu)？

為什么會產(chǎn)生架構(gòu)？

想象一下，在最早期，每個人都完全獨立生活，衣、食、住、行等等全部都自己搞定，整個人類都是獨立的個體，不相往來。為了解決人類的延續(xù)的問題，自然而然就有男女群居出現(xiàn)，這個時候就出現(xiàn)了分工了，男性和女性所做的事情就會有一定的分工，可是人每天生活的基本需求沒有發(fā)生變化，還是衣食住行等生活必須品。

但是一旦多人分工配合作為生存的整體，力量就顯得強大多了，所以也自然的形成了族群：有些人種田厲害，有些人制作工具厲害，有些地方適合產(chǎn)出糧食，有些地方適合產(chǎn)出棉花等，就自然形成了人的分群，地域的分群。當分工發(fā)生后，實際上每個人的生產(chǎn)力都得到了提高，因為做的都是每個人擅長的事情。

整個人群的生產(chǎn)力和抵抗環(huán)境的能力都得到了增強。為什么呢？因為每個人的能力和時間都是有限的，并且因為人的結(jié)構(gòu)的限制，人同時只能專心做好一件事情，這樣不得已就導(dǎo)致了分工的產(chǎn)生。既然分工發(fā)生了，原來由一個人干生存所必需的所有的事情，就變成了很多不同分工的角色合作完成這些事情，這些人必須要通過某些機制合在一起，讓每個人完成生存所必需的事情，這實際上也導(dǎo)致了交易的發(fā)生（交易這部分就不在這里展開了，有機會再討論）。

在每個人都必須自己完成所有生活必須品的生產(chǎn)的時候，是沒有架構(gòu)的（當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產(chǎn)生架構(gòu)的）。一旦產(chǎn)生的分工，就把所有的事情，切分成由不同角色的人來完成，最后再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的事情，并具備一定的交易能力即可。

這實際上就形成了社會的架構(gòu)。那么怎么定義架構(gòu)呢？以上面這個例子為例，把一個整體（完成人類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，并通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結(jié)合為一個整體，并完成這個整體所需要的所有活動，這就是架構(gòu)。由以上的例子，也可以歸納出架構(gòu)產(chǎn)生的動力：

必須由人執(zhí)行的工作（不需要人介入，就意味著不需要改造，也就不需要架構(gòu)了）

每個人的能力有限（每個人都有自己的強項，個人的產(chǎn)出受限于最短板，并且由于人的結(jié)構(gòu)限制，同時只能專注于做好一件事情，比如雖然有兩只眼睛，但是只能同時專注于一件事物，有兩只手，無法同時做不同的事情。ps. 雖然有少部分人可以左手畫圓右手畫框，但是不是普遍現(xiàn)象）

每個人的時間有限（為了減少時間的投入，必然會導(dǎo)致把工作分解出去，給擅長于這些工作的角色來完成，從而縮短時間）

人對目標系統(tǒng)有更高的要求（如果滿足于現(xiàn)狀，也就不需要進行架構(gòu)了）

目標系統(tǒng)的復(fù)雜性使得單個人完成這個系統(tǒng)，滿足條件2，3（如果個人就可以完成系統(tǒng)的提高，也不需要別的人參與，也就不需要架構(gòu)的涉及，只是工匠，并且一般這個工作對時間的要求也不迫切。當足夠熟練之后，也會有一定的架構(gòu)思考，但考慮更多的是如何提高質(zhì)量，提高個人的時間效率）

有人可能會挑戰(zhàn)說，如果一個人對目標系統(tǒng)進行分解，比如某人建一棟房子，自己采購材料，自己搭建，難道也不算架構(gòu)嘛？如果對于時間不敏感的話，是會出現(xiàn)這個情況的，但是在這種情況下，并不必然導(dǎo)致架構(gòu)的發(fā)生。如果有足夠的自覺，以及足夠的熟練的話，也會產(chǎn)生架構(gòu)的思考，因為這樣對于提高生產(chǎn)力是有幫助的，可以縮短建造的時間，并會提高房子的質(zhì)量。事實上建筑的架構(gòu)就是在長期進行這些活動后，積累下來的實踐。

當這5個條件同時成立，一定會產(chǎn)生架構(gòu)。從這個層面上來說，架構(gòu)是人類發(fā)展過程中，由懵懵懂懂的，被動的去認識這個世界，變成主動的去認識，并以更高的效率去改造這個世界的方法。以下我們再拿建筑來舉例加強一下理解。

最開始人類是住在山洞里，住在樹上的，主要是為了躲避其他猛獸的攻擊，以及減少自然環(huán)境的變化，對人類生存的挑戰(zhàn)。為了完成這些目標，人類開始學(xué)會在平地上用樹木和樹葉來建立隔離空間的設(shè)施，這就是建筑的開始。但是完全隔離也有很多壞處，慢慢就產(chǎn)生了門窗等設(shè)施。

建筑的本質(zhì)就是從自然環(huán)境中，劃出一塊獨占的空間，但是仍然能夠通過門窗等和自然環(huán)境保持溝通。這個時候架構(gòu)就已經(jīng)開始了。對地球上的空間進行切分，并通過門窗，地基等，保持和地球以及空間的有機的溝通。當人類開始學(xué)會用火之后，茅棚里面自然而然慢慢就會被切分為兩部分，一部分用來燒飯，一部分用來生活。當人的排泄慢慢移入到室內(nèi)后，洗手間也就慢慢的出現(xiàn)了。這就是建筑內(nèi)部的空間切分。

這個時候人們對建筑的需求也就慢慢的越來越多，空間的切分也會變成很多種，組合的方式也會有很多種，比如每個人住的房子，群居所產(chǎn)生的宗教性質(zhì)的房子，集體活動的房子等等。這個時候人們就開始有意識的去設(shè)計房子，架構(gòu)師就慢慢的出現(xiàn)了。一切都是為了滿足人的越來越高的需求，提升質(zhì)量，減少時間，更有效率的切分空間，并且讓空間之間更加有機的進行溝通。這就是建筑的架構(gòu)以及建筑的架構(gòu)的演變。　　總結(jié)一下，什么是架構(gòu)，就是： 根據(jù)要解決的問題，對目標系統(tǒng)的邊界進行界定。 并對目標系統(tǒng)按某個原則的進行切分。切分的原則，要便于不同的角色，對切分出來的部分，并行或串行開展工作，一般并行才能減少時間。 并對這些切分出來的部分，設(shè)立溝通機制。 根據(jù)3，使得這些部分之間能夠進行有機的聯(lián)系，合并組裝成為一個整體，完成目標系統(tǒng)的所有工作。 　　同樣這個思考可以展開到其他的行業(yè)，比如企業(yè)的架構(gòu)，國家的架構(gòu)，組織架構(gòu)，音樂架構(gòu)，色彩架構(gòu)，軟件架構(gòu)等等。套用三國演義的一句話，合久必分，分久必合。架構(gòu)實際上就是指人們根據(jù)自己對世界的認識，為解決某個問題，主動地、有目的地去識別問題，并進行分解、合并，解決這個問題的實踐活動。架構(gòu)的產(chǎn)出物，自然就是對問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合并的原則以及理由，以及拆分，拆分出來的各個部分和合并所對應(yīng)的角色和所需要的核心能力等。

架構(gòu)漫談（二）：認識概念是理解架構(gòu)的基礎(chǔ) 事實上，這些基礎(chǔ)概念對于做架構(gòu)是非常重要的，大部分人對于每天都習(xí)以為常的概念，都自以為明白了，但實際上都是下意識的，并不是主動的認識。比如說“什么是桌子？”，做培訓(xùn)的時候，我經(jīng)常拿這個例子來問大家，回答千奇百怪。這實際上就導(dǎo)致了做架構(gòu)的時候，不同角色的溝通會出很多問題，那么結(jié)果也就可想而知了。

如前一篇所說，架構(gòu)實際上解決的是人的問題，而概念是人認識這個世界的基礎(chǔ)，自然概念的認識就非常的重要。這篇文章嘗試討論一下，如何去認識概念。當然這篇不是語言學(xué)的文章，我這里所討論的，和語言學(xué)可能不太一樣，如果大家對語言學(xué)感興趣，也可以去參考一下。

首先我要先聲明一下，這一系列的文章，都是以人的認識為主體去討論的，解決的都是人的問題，任何沒有具體申明的部分，都隱含這一背景，以免大家誤解。

概念也屬于人認識這個世界并用來溝通的手段，包括“概念”這個概念，也是一樣的。在古代，不叫“概念”，稱之為“名相”。

何為相？

一般我們認為：看到一個東西，比方說杯子，“杯子”就是一個名字，指代的看到的東西就是相，就是事物的相狀。我們一聽到“杯子”這個詞，腦海里就會浮現(xiàn)出一個杯子的形象。而“杯子”這個詞，是用來指代的是這個相狀的，叫做名。合起來就叫做“名相”。

可是當我們把杯子打碎了的時候，我們還會稱這個碎了的東西叫杯子嗎？肯定不會，一般會叫“碎瓦片”，如果我們把碎瓦片磨碎了呢，名字又變了，叫做“沙子”。這就奇怪了，同樣一個東西，怎么會變出這么多的名字出來？

那究竟什么才是相？

實際上“相“表達的不是一個具體的東西，如上面所提的一個瓷器杯子，并不是指這個瓷器，而是這個瓷器所起的一個作用：一手可握，敞口（一般不超過底的大小，太大口就叫碗了），并且內(nèi)部有一個空間可乘東西的這么一個作用。并不是指這個瓷器本身。這也是為什么我們從電視上看到一個人拿杯子的時候，我們知道這個是杯子。但是實際上我們看到的都是光影而已。所以說相實際上代表的是這個作用，并不是具體的某個東西，而名是用來標識這個作用的，用來交流的。

為何需要這個作用？

這個作用其實是為了解決“人需要一個可單手持握，但是希望避免直接接觸所盛物體”這個問題。

所以說，每個概念實際上所解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了一個名字，這個名字就是對應(yīng)的某個特定的概念。對于概念這個詞本身，為了統(tǒng)一指代這些名字，我們稱起這類作用的名字稱為“概念”。我們上次討論的“架構(gòu)”也是是同樣的一個特定概念，這里不再詳述。同樣，什么是“建筑”？“建筑”實際上解決的就是“人需要獨占的空間，并還能夠比較流暢的和外部世界溝通”的問題。

再拿前面的“桌子”來舉例，什么叫“桌子”？很多人回答，四條腿，或者說有腿，有一個平面，等等，柜子不也是這樣嗎？為什么我們看到柜子，不會認為是桌子呢？即使我們放在柜子上吃飯，我們看到仍然會問，為什么在柜子上吃飯？不會叫桌子。如果明白了上面的道理，就很簡單了，桌子實際上是為了解決人坐在椅子上，手還能夠支撐在一個平面上繼續(xù)開展活動的問題，一般會和椅子配對出現(xiàn)。坐在椅子上工作，對著柜子有一個很嚴重的問題——不知道大家試過沒有——就是腿無法展開的問題。當這么坐著超過半小時就知道是什么痛苦了。所以桌子的平面下方一定會有一個足夠容納膝部和小腿的空間，來解決這個問題。解決了這些問題的裝置，才能稱之為桌子。

類似也可以定義出來椅子，由此可見，桌子和椅子的高度也是有限定的，都是是解決人的問題，要符合人的身高：椅子的高度和深度，必須符合小腿和大腿的長度；椅背的高度要配合脊柱的高度；桌子的高度要配合小腿和脊柱的高度之和；成人和小孩的自然也就有區(qū)別了。這又變成生理學(xué)了，事實上要做好桌子和椅子，必須要理解人的生理結(jié)構(gòu)，才能正確的理解桌子和椅子的概念。

同理，為何我們可以在不同的語言間進行翻譯，是因為雖然語言不同，但是人類所面臨的的問題是一樣的，所使用的名不同而已。對于不同的動物之間的翻譯也是同理。

關(guān)于抽象

在討論桌子這個概念的過程中，很多人會提出抽象這個概念，認為定義桌子實際上就是抽象的一個過程。這里，我覺得有必要要澄清一下抽象這個概念，我認為這個里面有誤解。我注意到，在做架構(gòu)師的群體中，不談抽象好像就不是一個合格的架構(gòu)師。

抽象這個詞代表的含義，實際上是把不同的概念的相似的部分合并在一起，形成一個新的概念。這個里面問題很多：首先“相似的部分”在不同的人看來，并不一定那么相似；其次，抽象之后形成的是一個新的概念，和原來那個概念并不一樣，所解決的問題也不一樣。所以我們不能用抽象來定義一個事物，抽象實際上是一個分類的過程，完全是另一碼事。再舉一個例子，杯子和容器，很多人認為容器是杯子的抽象，但是實際上杯子是杯子，容器是容器，它們所解決的問題是不一樣的。當我們需要解決裝東西的問題的時候，會說容器；當我們需要解決單手持握要裝東西的時候，會說要一個杯子。

回過頭來，根據(jù)架構(gòu)的定義，要做好架構(gòu)所首先必須具備的能力，就是能夠正確的認識概念，能夠發(fā)現(xiàn)概念背后所代表的問題，進而才能夠認識目標領(lǐng)域所需要解決的問題，這樣才能夠為做好架構(gòu)打好基礎(chǔ)。事實上，這一能力，在任何一個領(lǐng)域都是適用的，比如我們?nèi)绻胍獙W(xué)習(xí)一項新的技術(shù)，如Hibernate、Spring、PhotoShop、WWW、Internet等等，如果知道這些概念所要解決的問題，學(xué)習(xí)這些新的技術(shù)或者概念就會如虎添翼，快速的入手；學(xué)習(xí)一個新的領(lǐng)域，也會非常的快速有效；使用這些概念來解釋問題，甚至發(fā)明新的概念都是很容易的事。為什么強調(diào)這個呢，因為做架構(gòu)的時候，很多時候都是在一個新的領(lǐng)域解決問題，必須要快速進入并掌握這個領(lǐng)域，然后才能夠正確的解決問題。

以上通過幾個例子，討論了一下認識概念的誤區(qū)，如何有效的去認識概念，明白概念背后的含義，以及如何利用對概念的理解，快速的進行學(xué)習(xí)。掌握了這些原則，會有利于幫助我們在架構(gòu)階段，快速的識別和定位問題。

架構(gòu)漫談（三）：如何做好架構(gòu)之識別問題

按照之前架構(gòu)的定義，做好架構(gòu)首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那么問題就已經(jīng)解決80%了。這個能力基本上就決定了架構(gòu)師的水平。

那么面對問題有哪些困難呢?

我們先看一則笑話。女主人公：老公，把袋子里的土豆切一半下鍋。結(jié)果老公是把袋子里的每個土豆都削了一半，然后下鍋。

當然很多人會說，這個是溝通問題，然后一笑了之。其實，出現(xiàn)這個現(xiàn)象是由于我們大部分時候過于關(guān)注解決問題，急于完成自己的工作，而不關(guān)心“真正的問題是什么”而造成的。當我們?nèi)ソ鉀Q一個問題的時候，一定要先把問題搞清楚。這也是我為什么要單獨寫一篇文章講這個的原因。去看看軟件開發(fā)工作者的時間分配也可以看出，大家大部分時間花在討論解決方案和實現(xiàn)的細節(jié)上，基本都不會花時間去想“問題是什么”。或者即使想了一點點，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什么的工程師，才可能會真正的成長為架構(gòu)師

以這個笑話為例，看看在我們處理問題的時候，都會犯什么樣的錯誤：

被告知要處理一個問題，但是交過來的實際上是一個解決方案，不是問題本身。

被告知要處理一個問題，直接通過直覺就有了一個解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個合適。

那么如何識別問題呢?

所有的概念基本都有一個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結(jié)果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。

以上面切土豆的例子來分析：

女主人提出一個問題，要切土豆下鍋煮。

男主人有一個問題，女主人交代了自己必須要完成的一個任務(wù)。

每個人都是優(yōu)先處理自己的問題，自然就選擇了2，完成了這個任務(wù)。這也是大部分軟件工程師處理的方式，以自己認為對的方式完成自己的問題，沒什么不對啊，也難怪能得到我們的共鳴。這個里面犯的錯誤是什么呢?

女主人公提出的實際上是解決方案，而不是燒土豆這個問題本身。女主人當時執(zhí)行這個解決方案可能有困難，就把執(zhí)行解決方案作為一個任務(wù)，委托給了男主人。

男主人得到了一個任務(wù)，盡心盡職地把這個任務(wù)完成了。

最后的結(jié)果是什么呢，每個人都做了很多工作，每個人都認為自己做的是對的，因此沒有一個人對結(jié)果滿意。因為真正的問題沒有被發(fā)現(xiàn)，自然也就沒有被解決，那么后續(xù)還得收拾殘局，還要繼續(xù)解決問題。事實上自己的工作并沒有完成，反而更多了。把原因歸結(jié)為溝通問題也是可以的，但對于解決問題似乎并沒有太多的幫助。因為要改進溝通，這也是一個大問題。搞明白目標問題“是誰的問題，是什么問題”，當然也是需要溝通的。為了幫助自己更快的搞明白，首先要做的事是問正確的問題。架構(gòu)師應(yīng)該問的第一個正確的問題就是：目標問題是誰的問題。

當我們處理問題的時候，如果發(fā)現(xiàn)自己正在致力于把自己的工作完成，要馬上警惕起來，因為這樣下去會演變成沒有ownership的工作態(tài)度。在面對概念的時候，也會不求甚解，最終會導(dǎo)致沒有真正的理解概念。

作為軟件工程師或者架構(gòu)師，我們大部分時候是要去解決別人的問題，“別人”是誰，是值得好好思考的。在這個故事里面，男主人要解決的，實際上是這個家庭晚餐需要吃土豆的問題，目標問題的主體實際上是這個家庭的成員。

明白了問題的主體，這個主體就自然會帶來很多邊界約束，比如土豆是要吃的，要給人吃的，而且還是要給自己的家人吃的。“切土豆下鍋”這個問題，因為識別了問題的主體，自然而然的就附帶了這么多的信息。后續(xù)如何煮，是否放高壓鍋煮，放多少水，煮多長時間等等，就自然而然能夠問出來其他問題來了，說不定還能夠識別出來，女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題。可以想象，這樣下去最后的結(jié)果一定是大家都滿意的，因為真正的問題解決了。只有真正明白了是誰的問題，才能夠真正地完成自己的任務(wù)，真正地把自己的問題解決掉，而不是反過來。

由上面的分析可以看出，找出問題的主體，是做架構(gòu)的首要問題。這也是我一再強調(diào)的，我們要解決的問題，一定都是人的問題。更進一步，架構(gòu)師要解決的，基本都是別人的問題，不是自己的問題。再進一步，我們一定要明白，任何找上架構(gòu)師的問題，絕對都不是真正的問題。為什么呢? 因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構(gòu)師。架構(gòu)師都要有這個自覺：發(fā)現(xiàn)問題永遠都比解決問題來的更加重要。

當問題的主體離架構(gòu)師越遠，就會讓找出問題主體的過程越加困難，我們再舉一個軟件行業(yè)比較熟悉的例子：用戶給產(chǎn)品經(jīng)理提出要求，想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰，是用戶還是設(shè)計師還是施工隊? 如果產(chǎn)品經(jīng)理當成是自己的問題，那么毫無疑問就給了錘子了。

我們需要識別：用戶究竟是二傳手，還是問題的真正主體。如果是設(shè)計師，那么問題的邊界就變成了設(shè)計師的問題；如果是施工隊，那么問題就變成了施工隊的問題；如果是用戶，那么就要看看用戶到底有什么困難，絕對不是要一個錘子這么簡單。這也說明了，問題的主體對問題的邊界確定有多么的重要。

當明白了問題的主體，我們才可能真正的認識問題是什么。因為問題的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。一旦確定了主體，剩下的就是去搞明白主體有哪些問題。這個就比較直接了，常用的方式就是直接面對主體進行訪談，深入到主體的工作生活當中，體驗并感受這些問題，甚至通過數(shù)據(jù)的反饋來定位問題。這個大家就比較熟悉了，我就不展開了。

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

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

這是誰的問題？

有什么問題？

當?shù)玫降幕卮鹗侵е嵛岬臅r候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經(jīng)驗，問題1會花比較多的時間，也是支支吾吾最多的地方，因為架構(gòu)要解決的問題都是人的問題。但是一旦確定了答案，問題2就會變得非常容易。可以這樣說，架構(gòu)師的能力大部分會體現(xiàn)在問題1的識別上。

架構(gòu)漫談（四）：如何做好架構(gòu)之架構(gòu)切分

在識別出是誰的問題之后，會發(fā)現(xiàn)，在大部分情況下，問題都迎刃而解，不需要做額外的動作。很多時候問題的產(chǎn)生都是因為溝通的誤解，或者主觀上有很多不必要的利益訴求導(dǎo)致的。但是總還有一部分確實是有問題的，需要做調(diào)整，那么就必須要有所動作，做相應(yīng)的調(diào)整。這個調(diào)整就是架構(gòu)的切分。

切分就是利益的調(diào)整

我們要非常的清楚，所有的切分調(diào)整，都是對相關(guān)人的利益的調(diào)整。為什么這么說呢，因為維護自己的利益，是每個人的本性，是在骨子里面的，我們不能逃避這一點。我們以第一篇文章里面的例子為例來做解釋。

我們已經(jīng)知道，隨著社會的發(fā)展，分工是必然的，為什么呢? 這個背后的動力就是每個人自己的利益。每個人都希望能夠把自己的利益最大化，比如：生活的更舒適，更輕松，更安全，占用并享有更多的東西。但是每個人的能力和時間都非常的有限，不可能什么都懂，所以自然需要舍掉一些自己不擅長的東西，用自己擅長的東西去換取別人擅長的東西。

對比一個人干所有的事情，結(jié)果就是大家都能夠得到更多，當然也產(chǎn)生了一個互相依賴的社會，互相誰都離不開誰。這就是自然而然而產(chǎn)生的架構(gòu)切分，背后的原動力就是人們對自己利益的渴望。人們對自己利益的渴望也是推動社會物質(zhì)發(fā)展的原動力。

在這個模式下，比較有意思的是，每個人必須要舍掉自己的東西，才能夠得到更多的東西。有些人不愿意和別人進行交換，不想去依賴于別人，這些人的生活就很明顯的差很多，也辛苦很多，自然而然的就被社會淘汰了。如果需要在這個社會上立足，判斷標準就變成了：如何給這個社會提供更好更有質(zhì)量的服務(wù)。提供的更好更多的服務(wù)，自然就能夠換取更多更好的生活必需品。實際上這就是我們做人的道理。

為什么需要切分？

當人們認識到要主動的去切分一個系統(tǒng)的時候，毫無疑問，我們不能忘掉利益這個原動力。所有的切分決策都不能夠違背這一點，這是大方向。結(jié)合前一篇“識別問題”，一旦確定了問題的主體，那么系統(tǒng)的利益相關(guān)人（用現(xiàn)代管理學(xué)語言叫：stakeholder）就確定了下來。所發(fā)現(xiàn)的問題，會有幾種情況：

某個或者某些利益相關(guān)人負載太重。

時間上的負載太重。

空間上的負載太重，本質(zhì)上還是時間上的負載太重。

某個或者某些利益相關(guān)人的權(quán)利和義務(wù)不對等。

切分的原則

情況1是切分的原因，情況2是切分不合理而導(dǎo)致的新的問題，最終還是要回到情況1。對于情況1，本質(zhì)上都是時間上的負載。因為每個人的時間是有限的，怎么在有限的時間內(nèi)做出更多的事情？那么只有把時間上連續(xù)的動作，切分成時間上可以并行的動作，在空間上橫向擴展。所以切分就要有幾個原則：

必須在連續(xù)時間內(nèi)發(fā)生的一個活動，不能切分。比如孕婦懷孕，必須要10月懷胎，不能夠切成10個人一個月完成。

切分出來的部分的負責人，對這個部分的權(quán)利和義務(wù)必須是對等的。比方說媽媽10月懷胎，媽媽有權(quán)利處置小孩的出生和撫養(yǎng)，同樣也對小孩的出生和撫養(yǎng)負責。為什么必須是這樣呢? 因為如果權(quán)利和義務(wù)是不對等的話，會傷害每個個體的利益，分出來執(zhí)行的效率會比沒有分出來還要低，實際上也損害了整體的利益，這違背了提升整體利益的初衷。

切分出來的部分，不應(yīng)該超出一個自然人的負載。當然對于每個人的能力不同，負載能力也不一樣，需要不斷的根據(jù)實際情況調(diào)整，這實際上就是運營。

切分是內(nèi)部活動，內(nèi)部無任怎么切，對整個系統(tǒng)的外部應(yīng)該是透明的。如果因為切分導(dǎo)致整個系統(tǒng)解決的問題發(fā)生了變化，那么這個變化不屬于架構(gòu)的活動。當然很多時候當我們把問題分析的比較清楚的時候，整個系統(tǒng)的邊界會進一步的完善，這就會形成螺旋式的進化。但這不屬于架構(gòu)所應(yīng)該解決的問題。進化的發(fā)生，也會導(dǎo)致新的架構(gòu)的切分。

原則2是確保我們不能違反人性，因為維護自己的利益，是每個人的本性。只有權(quán)利和義務(wù)對等才能做到這一點。從原則2的也可以推理，所有的架構(gòu)分拆，都應(yīng)該是形成樹狀的結(jié)果，不應(yīng)該變成有向圖，更不應(yīng)該是無向圖。很多人一談架構(gòu)，必談分層，但是基本上都沒意識到，是因為把一個整體分拆為了一棵樹，因為有了樹，才有層。

從某種意義上來說，談架構(gòu)就是談分層，似乎也沒有錯，但是還是知道為什么比較好。從根節(jié)點下來，深度相同的是同一層。這個是數(shù)學(xué)概念，我就不展開了，感興趣可以去復(fù)習(xí)一下數(shù)學(xué)。

同樣我們看一個組織架構(gòu)，也可以做一個粗略的判斷，如果一個企業(yè)的組織架構(gòu)出現(xiàn)了“圖”，比方說多線匯報，一定是對stakeholder的利益分析出現(xiàn)了問題，這就會導(dǎo)致問題2的發(fā)生。問題2一旦出現(xiàn)，我們必須馬上要意識到，如果這個問題持續(xù)時間長，會極大的降低企業(yè)的運作效率，對相關(guān)stakeholder的利益都是非常不利的，同樣對于企業(yè)的利益也是不利的。必須快速調(diào)整相關(guān)stakeholder的職責，使得企業(yè)的組織架構(gòu)成為一個完美的樹狀，并且使得樹的層數(shù)達到盡可能的低。只有平衡樹可以比較好的達到這個效果。

當然如果某個節(jié)點的能力很強，也可以達到減小樹的高度的結(jié)果。技術(shù)的提升，也是可以提升每個節(jié)點的能力，降低樹的層數(shù)。很多管理學(xué)都在討論如何降低組織架構(gòu)的層數(shù)，使得管理能夠扁平化，原因就在于此，這里就不展開討論了。從這里也基本可以得出一個結(jié)論，一個好的組織的領(lǐng)導(dǎo)，一定也是一個很好的架構(gòu)師。

切分與建模

實際上切分的過程就是建模的過程，每次對大問題的切分都會生成很多小問題，每個小問題就形成了不同的概念。這也是系列第二篇文章嘗試表達的。這些不同的概念大部分時候人們自發(fā)的已經(jīng)建好了，架構(gòu)師更多的是要去理解這些概念，識別概念背后所代表的的人的利益。比如人類社會按照家庭進行延續(xù)，形成了家族，由于共享一片土地資源，慢慢形成了村莊，村莊聯(lián)合體，不同地域結(jié)合，形成了國家。由于利益分配的原因，形成了政權(quán)。每次政權(quán)的更迭，都是利益重新分配的動力所決定的。

同樣對于一個企業(yè)也是一樣的，一開始一個人干所有的事情。當業(yè)務(wù)量逐漸變大，就超過了一個人能夠處理的容量，這些內(nèi)容就會被分解出來，開始招聘人進來，把他們組合在一起，幫助處理企業(yè)的事務(wù)。整個企業(yè)的事務(wù)，就按照原則2，分出來了很多新的概念：營銷，售前，售中，售后，財務(wù)，HR等等。企業(yè)的創(chuàng)始人的工作就變成了如何組合這些不同的概念完成企業(yè)的工作。如果業(yè)務(wù)再繼續(xù)增大，這些分出來的部分還要繼續(xù)分拆，仍然要按照原則2才能夠讓各方達到利益最大化。如果某個技術(shù)的提升，提高了某個角色的生產(chǎn)力，使得某個角色可以同時在承擔更多的工作，就會導(dǎo)致職責的合并，降低樹的層數(shù)。

切分的輸出和組織架構(gòu)

架構(gòu)切分的輸出實際上就是一個系統(tǒng)的模型，對于一個整體問題，有多少的相關(guān)方，每個相關(guān)方需要承擔哪些權(quán)利和義務(wù)，不同的相關(guān)方是如何結(jié)合起來完成系統(tǒng)的整體任務(wù)的。有的時候是從上往下切（企業(yè)），有的時候是從下往上合并，有的時候兩者皆有之（人類社會的發(fā)展）。而切分的結(jié)果最終都會體現(xiàn)在組織架構(gòu)上，因為我們切分的實際上就是人的利益。

從這方面也可以看出，任何架構(gòu)調(diào)整都會涉及到組織架構(gòu)，千萬不可輕視。同樣，如果對于stakeholder的利益分析不夠透徹，也會導(dǎo)致架構(gòu)無法落地，因為沒有人愿意去損壞自己的利益。一旦強制去執(zhí)行，人心就開始潰散。這個也不一定是壞事，只要滿足原則2就能夠很好的建立一個新的次序和新的利益關(guān)系，保持組織的良性發(fā)展，長久來看是對所有人的利益都有益的，雖然短期內(nèi)有對某些既得利益者會有損害。

總結(jié)一下

架構(gòu)的切分的導(dǎo)火索是人的負載太重。

架構(gòu)的切分實際就是對stakeholder的利益進行切分或合并，使得每個stakeholder的權(quán)責是對等的，每個stakeholder可以為自己的利益負責。

架構(gòu)切分的最終結(jié)果都會體現(xiàn)在組織架構(gòu)上，只有這樣才能夠讓架構(gòu)落地并推進。

架構(gòu)切分的結(jié)果一定是一個樹狀，這也是為什么會產(chǎn)生分層。層數(shù)越多溝通越多，效率越低，分層要越少越好。盡可能變成一顆平衡樹，才能讓整個系統(tǒng)的效率最大化。

架構(gòu)漫談（五）：什么是軟件

馮諾依曼結(jié)構(gòu)，圖靈機，以模擬人為目標

軟件的歷史，實際上可以說是用機器模擬人的歷史。不管大家（包括在這個歷史過程中的參與者）有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。從馮諾依曼結(jié)構(gòu)開始，程序邏輯開始脫離硬件，采用二進制編碼。加上存儲，配合輸入輸出，一個簡化的大腦就出現(xiàn)了。圖靈機則是模擬大腦的計算，用數(shù)學(xué)的方式把計算的過程定義了出來，著名的邱奇-圖靈論題：一切直覺上能行可計算的函數(shù)都可用圖靈機計算，反之亦然。軟硬件兩者一結(jié)合，一個可編程的大腦出現(xiàn)了，這也是現(xiàn)在為什么我們把計算機叫做電腦。在硬件上編寫出的程序，就是軟件，是用來控制硬件的行為的。

成本為王

在初期，軟件使用二進制編寫的，從硬件到軟件，成本都非常的高。隨著半導(dǎo)體技術(shù)的進步，硬件的成本越來越低，性能越來越高，甚至出現(xiàn)了摩爾定律：當價格不變時，集成電路上可容納的元器件數(shù)目，約每隔18-24個月增加一倍，性能提升一倍。軟件方面，為了簡化難度，開始采用匯編，進一步出現(xiàn)了類似于人類的語言的高級語言，比如C/C++/Java等，這使得人類可以用類似于人的語言來和計算機溝通。軟件工程師慢慢越來越多，開發(fā)軟件的成本也越來越低。計算機就好像是一個只需要電，不需要休息的人，可以無休無止的工作。

人們越來越愿意把原來只有人才能做的事情，交給計算機來做。結(jié)果就導(dǎo)致軟件越來越豐富，能夠做的事情也越來越多，成本也越來越低。可以這么說，成本是我們?yōu)槭裁床捎密浖闹饕獎恿Γ梢怨?jié)省大量的人員培訓(xùn)，減少雇員的數(shù)目。隨著互聯(lián)網(wǎng)的發(fā)展，人類社會也開始軟件化了。原來必須實體店來進行售賣的，搬到互聯(lián)網(wǎng)上，開店成本更低，并且能夠接觸到更多的人。想象一下，一個門店每天的人流達到百萬級別是很恐怖的，由實體空間大小來決定。但是在互聯(lián)網(wǎng)上，訪問量千萬級別都不算什么。最終的結(jié)果就變成，每個人能夠負擔的工作越來越多，成本越來越低。這也是為什么軟件這么熱的原因。

軟件扮演的角色

隨著軟件的規(guī)模的變大，做好一個軟件也變得越來越難了。早期的程序員寫程序，主要是為了幫助自己研究課題。這些程序員熟練了之后，提高了自己的生產(chǎn)力，并發(fā)現(xiàn)還可以幫助別人寫程序，慢慢軟件就變成了一個獨立的行業(yè)。程序從早期由一個人完成，也逐漸變成了由很多不同角色的人共同合作來完成。以下討論的前提，都是基于幫助別人寫程序，多人合作的基礎(chǔ)上的。結(jié)論對于單人為自己寫程序也適用。

在沒有軟件之前，每個人干自己的工作，自行保存自己的工作結(jié)果。人們面對面或者通過電話等溝通，如下圖所示。

有了軟件之后，實際上，我們是把我們?nèi)粘Ｉ钪兴龅氖虑椋ㄎ覀冏约罕救硕家黄鹛摂M化到了計算機中。而人則演化成了，通過計算機的輸入輸出設(shè)備，控制計算機中的自己，來完成日常的工作，以及與其他人的溝通。也就是說，軟件一直以來的動力，始終都是來模擬人和這個社會的。比如模擬大氣運動（天氣預(yù)報），模擬人類社會（互聯(lián)網(wǎng)社交），模擬交易，包括現(xiàn)在正在流行的VR，人工智能等等。模擬的對象越來越高級，難度越來越大。

不管如何發(fā)展，模擬人的所有行為都是一個大的趨勢。也就是說，軟件的主要目的，還是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個角度來看，軟件主要依賴的還是人類的生活知識。軟件更多的是扮演一個cost center，這也是為什么會出現(xiàn)很多的軟件代工。

軟件開發(fā)的架構(gòu)演變

軟件工程師是實現(xiàn)這個模擬過程的關(guān)鍵人物，他必須先理解人是怎么在日常生活中完成工作的，才能夠很好的把這些工作在計算機中模擬出來。可是軟件工程師需要學(xué)習(xí)大量的計算機語言和計算機知識，還需要學(xué)習(xí)各行各業(yè)的專業(yè)知識。軟件工程師本身的培養(yǎng)就比較難，同時行業(yè)知識也要靠時間的積累，這樣就遠遠超出了軟件工程師的能力了。所以軟件開發(fā)就開始有分工了，行業(yè)知識和業(yè)務(wù)的識別，會交給BA，系統(tǒng)的設(shè)計會交給架構(gòu)師，設(shè)計的實現(xiàn)交給架構(gòu)師，實現(xiàn)的檢驗交給測試，還有很多其他角色的配合。為了組織這些角色的工作，還有項目經(jīng)理。這就把原來一個人的連續(xù)工作，拆分成了不同角色的人的連續(xù)配合，演化成了不同的軟件開發(fā)的模式。然后慢慢演變出專門為別人開發(fā)軟件的軟件公司。

軟件架構(gòu)的出現(xiàn)

如同前面描述的架構(gòu)的定義，軟件架構(gòu)的出現(xiàn)也是同樣的。一開始是懵懵懂懂的去寫軟件，后來慢慢的就有意識的去切分，演變成了不同的架構(gòu)。這個背后的動力也是一樣的，就是提升參與的人的利益，降低成本。導(dǎo)火索也是軟件工程師的任務(wù)太重，我們需要把很多工作拆分出來。拆分的原則也是一樣的，如何讓權(quán)責一致。同樣，這個拆分也是需要組織架構(gòu)的調(diào)整，來保證架構(gòu)的落地。具體如何分拆，如何調(diào)整，我們將在另外一篇中著重討論。

以上通過簡單的描述計算機和軟件的發(fā)展歷史，闡明軟件的本質(zhì)，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產(chǎn)力，提升人類自己的利益。軟件工程師的職責在這個浪潮中，不堪重負，自然而然就分拆為不同的角色，形成了一個獨特的架構(gòu)體系。這一切的背后，仍然是為了提升人類自己的利益，解決人類自己的問題。

架構(gòu)漫談（六）：軟件架構(gòu)到底是要解決什么問題？

要解決誰的問題？

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

一、業(yè)務(wù)問題

具體的現(xiàn)實生活狀態(tài)下，沒有軟件的時候，所解決的問題的主體是誰，解決的是什么問題，是如何解決，如何運作的？

二、計算機問題

如何把現(xiàn)實生活用軟件來模擬？

模擬出來的軟件，需要哪些硬件設(shè)施才能夠滿足要求？并且當訪問量越來越大的時候，軟件能否支持硬件慢慢長大，性能線性擴展？

因為硬件是可能會失效的，軟件如何在硬件失效的情況下，仍然能夠保證可用性，讓用戶能夠不中斷的訪問軟件提供的服務(wù)？

怎么收集軟件產(chǎn)生的數(shù)據(jù)，為下一階段的工作提供依據(jù)？

分別是誰的問題呢？

業(yè)務(wù)的owner需要提升業(yè)務(wù)的效率，降低業(yè)務(wù)的成本，這是動機。這個實際上就是業(yè)務(wù)的問題，所以一般軟件開發(fā)的出發(fā)點就在這里。

是軟件工程師的問題，要解決業(yè)務(wù)owner把業(yè)務(wù)虛擬化的問題，并且要解決軟件開發(fā)和運營的生命周期的問題。

分別有什么問題？

業(yè)務(wù)問題的本質(zhì)，是業(yè)務(wù)所服務(wù)的對象的利益問題，明白了這個，就很容易搞清業(yè)務(wù)的概念和組織方式。再次強調(diào)一下，有了軟件，可以降低業(yè)務(wù)的成本，沒有軟件的情況下，業(yè)務(wù)是一樣跑的。如果只是為了跟風(fēng)要用軟件，說不定反而提高了成本，這個是采用軟件之前首先要先搞清楚的。我們經(jīng)常說軟件和技術(shù)是業(yè)務(wù)的enabler，實際就是把原來成本很高的降到到了很低的程度而已，并不是有了什么新的業(yè)務(wù)。另外，軟件也不是降低業(yè)務(wù)成本的唯一方式。

為了能夠讓軟件很好的跑起來，軟件工程師必須理解業(yè)務(wù)所服務(wù)的對象，他們的利益所在，即業(yè)務(wù)問題。業(yè)務(wù)面對這些問題是如何分拆解決的？涉及到了哪些概念？這些概念分別解決了哪些哪些問題？我們不能自己按照自己的理解，用自己的一套概念體系來表述。如果這么做的話，會導(dǎo)致兩個問題：1）業(yè)務(wù)無法和我們交流，因為他們無法明白我們所自己創(chuàng)建的概念，所以他們無法確認我們的理解是否正確。2）我們所表述的東西，并沒有在實際生活中實踐過，我們也不知道這些概念是否能夠解決業(yè)務(wù)的問題。

軟件工程師還必須要考慮，用什么樣的硬件把軟件跑起來，怎樣跑得好，跑得快，并且可以隨著業(yè)務(wù)的流量逐漸的長大？

分析問題

對于2，在有限的時間下，軟件工程師毫無疑問無法一個人去完成這么多事情，那么我們需要把所做的事情列出來，進行分析。

一、虛擬化業(yè)務(wù)需要完成這些事情：

學(xué)習(xí)業(yè)務(wù)知識，認識業(yè)務(wù)所涉及的stakeholders的核心利益述求，以及業(yè)務(wù)是如何分拆滿足這些利益訴求，并通過怎樣的組織架構(gòu)完成整個組織的核心利益的，以及業(yè)務(wù)運作的流程，涉及到哪些概念，有哪些權(quán)利和責任等。

通過對業(yè)務(wù)知識的學(xué)習(xí)，針對這些概念所對應(yīng)的權(quán)利和責任以及組織架構(gòu)，對業(yè)務(wù)進行建模，并把建模的結(jié)果用編程語言實現(xiàn)。這是業(yè)務(wù)的模型，通常是現(xiàn)實生活中利益斗爭的結(jié)果，是非常穩(wěn)定的。

學(xué)習(xí)業(yè)務(wù)所參與的stakeholder是如何和業(yè)務(wù)打交道，并完成每個人的權(quán)利和義務(wù)的，并通過編程語言，結(jié)合業(yè)務(wù)模型實現(xiàn)這些打交道的溝通通道。這部分是變化最頻繁的，屬于組合關(guān)系。明白了這一點，對后續(xù)的實現(xiàn)非常有幫助。

如何把業(yè)務(wù)運行的結(jié)果持久化，并通過合適的手段把持久化后的數(shù)據(jù)，在合適的時間合適的地點加載出來。這部分和基礎(chǔ)設(shè)施有關(guān)，變化可能也會比較頻繁。

二、代碼如何運營，需要完成這些事情：

需要多少硬件設(shè)備來滿足訪問的需求？

代碼要分成多少個組件部署到哪些硬件設(shè)備上？

這些代碼如何通過硬件設(shè)備互相連接在一起？

當業(yè)務(wù)流量增大到超過一臺機器的容量時，軟件能否支持通過部署到新增機器上的方式，擴大對業(yè)務(wù)的支撐？

當某臺或某些硬件設(shè)備失效時，軟件是否仍然能夠不影響用戶的訪問。

軟件運行產(chǎn)生的數(shù)據(jù)，能否支持提取出來并加以分析，為下一輪的業(yè)務(wù)決策提供依據(jù)。

三、如果分成不同的角色來完成這些事情，就需要一個組織架構(gòu)來組織代碼的編寫和運營，需要做哪些事情：

完成一和二所列的這些事情，需要哪些角色參與？

這些事情基本都需要順序的發(fā)生，如何保證信息在不同角色的傳遞過程中不會有損失？或者說即使有損失，也能快速糾正？

這些角色之間是如何協(xié)調(diào)，才能共同完成虛擬化業(yè)務(wù)的需求？

會生成哪些架構(gòu)

如果業(yè)務(wù)足夠簡單，用戶流量夠小，時間要求也不急迫，那么一個人，一臺機器就夠了，這個時候一般不會去討論架構(gòu)的問題。當訪問的流量越來越大，機器就會越來越多，代碼的部署單元就會拆分的越來越多。

同樣就會需要越來越多的人來完成拆分出來的越來越多的部署單元，甚至同一個部署單元也需要分拆為多人合作完成。但是我們需要注意到一點，整個的概念體系，或者說業(yè)務(wù)的建模不會有任何的變化，還是完成同樣的這些事情。唯一的區(qū)別就是量越來越大，超過了單個人和單個機器的容量，不斷地增長。這樣就會導(dǎo)致以下的架構(gòu)：

當流量越來越大，我們就會發(fā)現(xiàn)，軟件所部屬的機器就會開始按照樹狀的結(jié)構(gòu)開始分拆，就會形成硬件的部屬架構(gòu)。這就是為什么會形成部署的分層。

為了把業(yè)務(wù)在軟件中實現(xiàn)并落地，需要前端人員、業(yè)務(wù)代碼人員、存儲層等不同技巧的人同時工作，需要切分成代碼的架構(gòu)。這就是為什么會形成代碼的分層，形成代碼的架構(gòu)。當然，當這些角色由一個人來完成的時候，不一定會有代碼架構(gòu)，往往會比較亂。

當參與的人員越來越多，就會形成開發(fā)體系的組織架構(gòu)。因為代碼開發(fā)的過程是一個連續(xù)的過程，會用流程來把不同的角色串聯(lián)起來，這就是軟件工程。

為了完成業(yè)務(wù)的工作，需要識別出來業(yè)務(wù)架構(gòu)和支撐業(yè)務(wù)的組織架構(gòu)，以及業(yè)務(wù)運作的流程。這是被虛擬化的業(yè)務(wù)架構(gòu)和組織架構(gòu)，也需要體現(xiàn)在代碼中，保持和現(xiàn)實生活中一致。

什么是軟件架構(gòu)

這就是軟件比較復(fù)雜的地方，涉及到軟件本身的業(yè)務(wù)體系，和所虛擬的業(yè)務(wù)體系。根據(jù)以上的分析，所生成的架構(gòu)，究竟那些算是軟件架構(gòu)呢？

軟件因為流量增大而分拆成不同的運行單元，在不同的機器上部署所形成的架構(gòu)，屬于軟件架構(gòu)。

每個運行單元為了讓不同角色的人，比如前端，業(yè)務(wù)，數(shù)據(jù)存儲等能夠并行工作，所分成的代碼架構(gòu)，也屬于軟件架構(gòu)。

所以當我們說軟件架構(gòu)的時候，我們一定要講清楚，究竟說的是部署的架構(gòu)，還是代碼的架構(gòu)。軟件架構(gòu)的落地，需要軟件的組織架構(gòu)和流程來保障，離開了這個，軟件架構(gòu)是一句空話。

另外很多人講，架構(gòu)是進化出來的。架構(gòu)實際上是在量不斷的增大，超過了單臺服務(wù)器的容量，逐漸的分拆，同時導(dǎo)致超過單個人員的能力，工作人員不斷的增多，工作內(nèi)容不斷的分拆形成的。這本身就是架構(gòu)的意義所在。不管怎么分拆，所達到的目標沒有任何變化，就是完成業(yè)務(wù)在計算機中的虛擬化。

架構(gòu)漫談（七）：不要空設(shè)架構(gòu)師這個職位，給他實權(quán)

什么是架構(gòu)師

架構(gòu)師的前提條件

如果一個人在工作中，只是致力于完成自己的工作，以做好自己的工作為主要目標，那么最多只能成為一個工匠，無法成為一個架構(gòu)師。因為這個過程解決的還是自己的問題，并沒有時間的壓力，可以隨意什么時候做完都可以。

當我們所做的工作是處于社會的分工的一環(huán)，需要幫助別人解決問題，并且按時解決別人的問題成為我們自己的問題的時候，我們就有了時間壓力，潛意識里會自然而然的有一種對時間的恐懼。這個恐懼在潛意識里面會想方設(shè)法推動我們采用各種手段，以便及時的完成工作，換取報酬。甚至?xí)影嗉狱c，不擇手段。

如果我們還生活在這個恐懼下面，是不可能成為架構(gòu)師的。要成為架構(gòu)師，必須要超越這個恐懼才能夠看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因為僅僅是完成了自己的工作，也并不一定就解決了別人的問題。如果別人的問題沒有解決——即使我們認為自己的工作完成了——我們的工作實際也沒完成，因為我們工作是否完成，是別人說了算的，不是我們自己。

為什么會有這個對時間的恐懼和壓力呢？這是因為我們把完成自己的工作當成了我們的最大利益。如果別人的問題沒有真正的解決，必然會覺得付出的報酬不值得，我們的利益實際上是受損失了。這和我們所以為的恰恰相反，因為我們所能得到的工作只會越來越少，別人會越來越不愿意依賴于我們。

另一方面也說明，我們對自己所從事的工作，還沒有足夠的自信，我們解決自己的問題還有困難，才會這么在意，并恐懼。如果我們把完成別人工作當成自己的最大利益，這個對時間的恐懼自然就會消失，這個時候就自然而然的開竅了，就知道怎么去發(fā)現(xiàn)問題了。只有做到這一點，才能在自己所服務(wù)的領(lǐng)域建立起自信，成為一個合格的架構(gòu)師。

其實剛開始一般是硬著頭皮去克服對時間的恐懼和壓力的，一點自信都沒有。但只要做成功了一次（只要真的舍得這么去做了，想不成功也很難！），自信就開始慢慢建立起來了，這個時候就是我們開始慢慢變成架構(gòu)師的時候。大家就當著上當一回，試試看。

如何發(fā)現(xiàn)“是誰的問題”

當我們真正專注于別人的問題的時候，我們自己的理想，抱負，對技術(shù)的追求都不算什么了。這些理想，抱負，對技術(shù)的最求，不就是要達到自己的利益嗎？只有幫助別人解決了問題，這些理想，抱負，對技術(shù)的追求才可能實現(xiàn)，否則這些理想，抱負，對技術(shù)的追求有什么意義，能得到什么利益？

這個時候就會真正的開始思考，別人究竟有什么問題。其實也很簡單，和我們自己面臨的問題一樣，別人的問題也都是如何獲取更好更多的利益。我們自己想明白了這一點，自然也就能想明白別人的問題。這個時候就能夠問出正確的問題：如果問題不解決，究竟誰會有利益的損失？如果問題解決了，究竟誰會有收益，誰的收益最大？回答了這兩個問題就找到了問題的主體。只回答一個是沒有用的，因為很多時候這個世界的事情，權(quán)責是不對等的。明白了這兩個問題，我們只要讓事情權(quán)責對等起來，讓每個人為自己的權(quán)利產(chǎn)生的結(jié)果負有義務(wù)，大部分時候我們自己根本就不需要做什么，問題就都解決了。這就是最高明的架構(gòu)師。

架構(gòu)師的權(quán)利和義務(wù)

架構(gòu)師是要去平衡別人的利益，甚至?xí){(diào)整別人的利益的。一旦架構(gòu)師是全心全意的為別人的利益服務(wù)，自然而然的架構(gòu)師就擁有了強有力的影響力，肯定會是一個leader。但是只是民意上的leader是沒有用的，不能完全發(fā)揮架構(gòu)師的能量。

架構(gòu)師必須是一個組織的領(lǐng)導(dǎo)人，有權(quán)利調(diào)動這個組織的架構(gòu)，才能夠更好的發(fā)揮架構(gòu)師的作用，更好的把利益的調(diào)整落到實處。所以很多公司設(shè)了很多架構(gòu)師的職位，但是并不具備調(diào)動組織架構(gòu)的權(quán)利，那么這個架構(gòu)師的職位一定是形同虛設(shè)。架構(gòu)師只能夠通過建立某些流程來行使架構(gòu)師的權(quán)利，比如強制架構(gòu)review，反而會造成很多內(nèi)部不必要的沖突，最終都會導(dǎo)致這些流程流于形式，得不償失。相信很多人都已經(jīng)經(jīng)歷過這些，但似乎很少有人回去探討這是為什么。

反過來，具備架構(gòu)師能力的組織領(lǐng)導(dǎo)人，一定是一個很好的領(lǐng)導(dǎo)，這個組織一定是很健康向上的，因為每個人的權(quán)利和義務(wù)就是比較均等的。并且這類領(lǐng)導(dǎo)對于組織成員權(quán)利和義務(wù)的對等狀況會非常的敏感，會及時的調(diào)整組織架構(gòu)，在問題發(fā)生之前就解決了。這樣這個組織就會具備更好的抗壓能力，能夠更好的為這個組織的客戶服務(wù)，這個組織的成員內(nèi)心一定都是比較平衡的，每個人的能力都能夠得到比較好的發(fā)展。當然讀者可能又會說，這不是管理學(xué)的東西嗎？是的，但也是架構(gòu)的問題。所有架構(gòu)的核心就是組織架構(gòu)。或者也可以這樣說，一個合格的組織領(lǐng)導(dǎo)人，一定必須是一個合格的架構(gòu)師。

架構(gòu)師的義務(wù)似乎不用說了，大家提的要求可能比我提的都高 —— 當然是發(fā)現(xiàn)問題并且解決問題。架構(gòu)師必須能夠超越對時間的恐懼 —— 也就是說必須具備了一定程度的自信，哪怕是裝的，去真正的發(fā)現(xiàn)問題的主體，識別真正的問題，并把這個行為變成為自己面對問題的第一反應(yīng)。架構(gòu)師還必須要明白，所給出的解決方案 —— 架構(gòu)的分拆、合并方案，只有讓問題的主體的權(quán)責對等，才能夠真正的解決別人的問題。一般明白了問題的主體，以及主體的利益所在，做到這一點也沒有問題。

架構(gòu)師和技術(shù)

很多人會問，特別是做軟件行業(yè)的，架構(gòu)師是不是需要學(xué)習(xí)技術(shù)，甚至是學(xué)習(xí)語言？如果一個架構(gòu)師還有這個困擾——就如問這個問題的人，說明目前還不具備做架構(gòu)師的能力，或者說還不具備對自己領(lǐng)域——哪怕是技術(shù)領(lǐng)域——的自信，更別談業(yè)務(wù)領(lǐng)域了。

因為技術(shù)和語言，都是用來識別和解決所服務(wù)的主體的權(quán)責，保護并提升所服務(wù)的主體的權(quán)利的。特別對于軟件領(lǐng)域來說，必須明白軟件本身是怎么回事，解決什么問題，還要解決軟件所服務(wù)的對象的領(lǐng)域本身是怎么回事，解決什么問題，這就要求更高了。語言和技術(shù)應(yīng)該是隨手拈來才對，對于架構(gòu)師這些都是工具。學(xué)習(xí)技術(shù)和語言，如果明白了這些技術(shù)和語言要解決的是誰的問題，什么問題，學(xué)起來是非常快，非常容易的。

同樣，采用哪個技術(shù)或者語言，只要某個技術(shù)或語言所解決的問題的主體，以及所解決的問題，和自己所面對的問題的主體和這個主體要解決的問題，這兩者是匹配的，那么這個方案的成本是最低的，所采用的技術(shù)或者語言就是靠譜的。沒有趁手的工具或語言的情況下，自己設(shè)計一個也不難，因為很清楚自己要什么。要不要自己做，無非是一個成本問題，也就是利益問題。并且從這個思路下去，選擇的工具和語言肯定都是最簡單的，成本是最低的。因為架構(gòu)畢竟解決的還是人的利益問題，成本越低越好，這個成本當然是長期總體成本，不是眼前的短期成本。

架構(gòu)漫談（八）：從架構(gòu)的角度看如何寫好代碼

軟件架構(gòu)實際上包括了：代碼架構(gòu)，以及承載代碼運行的硬件部署架構(gòu)。實際上，硬件部署架構(gòu)最終還是由代碼的架構(gòu)來決定。因為代碼架構(gòu)不合理，是無法把一個運行單元分拆出多個來的，那么硬件架構(gòu)能分拆的就非常的有限，整個系統(tǒng)最終很難長的更大。

所以我們經(jīng)常會聽說，重寫代碼，推翻原有架構(gòu)，重新設(shè)計等等說法，來說明架構(gòu)的進化。這實際上就是當初為了完成任務(wù)，沒有充分思考所帶來的后果。這也并不是架構(gòu)進化的事情，而是個人對問題領(lǐng)域的逐漸深入理解的過程。所以有必要再討論一下，代碼的架構(gòu)應(yīng)該是怎樣的。

如何把架構(gòu)的思考進行落地，細化到我們代碼的實踐當中，盡量不要讓代碼成為系統(tǒng)長大的瓶頸，降低架構(gòu)分拆的成本?

在前面我們提到，軟件實際上是對現(xiàn)實生活的模擬，虛擬化。這是一個非常重要的前提，直接決定了我們的代碼應(yīng)該分為幾部分。結(jié)合每個部署單元所承擔的責任，可以明確的拆分為兩個不同的責任：

表達業(yè)務(wù)邏輯的代碼。很多人把這部分叫做Domain Logic，或者叫Domain Model。這部分實際是來源于生活的，必須保持和現(xiàn)實生活中的切分一致，并非人為的抽象而成。

對用戶提供訪問并保存業(yè)務(wù)邏輯運行結(jié)果的代碼。計算機的狀態(tài)保存有一個缺陷，本機保留業(yè)務(wù)運行結(jié)果有很大的問題，一般都在外存儲設(shè)備上保存，也便于擴展。

所以單個部署單元的代碼可以分為兩個部分，如下圖所示：

從這個圖中可以看出，軟件代碼的相關(guān)利益人為運行時的訪問人員和存儲設(shè)備。而service的代碼是最復(fù)雜的，需要服務(wù)于三方，代碼人員的負擔是最重的。為了把這三方的變化對service的影響降到最低，對于service還必須進一步的分拆為三個部分，讓每一個部分都能夠獨立的變化，這樣這三方的變化就不會產(chǎn)生連鎖響應(yīng)，降低成本。如下圖所示：

這樣，就劃分成了幾個責任：

Service就專注于user的需求，并組合Glue Code提供的服務(wù)完成需求。

Glue Code專注于組合business的調(diào)用，管理Business里面對象的生命周期，并且通過Repository保存或加載Business的狀態(tài)

Business專注于實現(xiàn)業(yè)務(wù)的核心模型。

Repository專注于數(shù)據(jù)的保存，并和存儲設(shè)備一一對應(yīng)。

大家注意看，還是樹形架構(gòu)。并且左側(cè)的主要需要計算機的相關(guān)理論知識，并且要直接面對用戶的需求。右側(cè)的更多的需要面對業(yè)務(wù)的核心。只要這幾塊的開發(fā)人員互相商量好了接口定義，這幾個部分的開發(fā)就可以并行的進行，極大的提升開發(fā)的效率，縮短開發(fā)的時間。要做好這幾部分，還需要注意，邏輯只允許存在于Business中，Service、Glue Code、Repository都不允許存在業(yè)務(wù)邏輯。為什么呢？首先我們來看看什么叫業(yè)務(wù)邏輯。

什么叫業(yè)務(wù)邏輯？

首先這個定義的前提是指軟件代碼中的邏輯，不是現(xiàn)實生活中的邏輯。在軟件代碼中，不需縮進和計算的順序調(diào)用，包括縮進的代碼目的是catch exception的，都不算邏輯，除此以外都是邏輯。以下用嚴格的順序調(diào)用來指代這種代碼。因為順序調(diào)用是計算機的特性，由編譯器來決定的，當然最本質(zhì)的是因為我們計算的基礎(chǔ)都是圖靈機。在現(xiàn)實生活中，順序調(diào)用也是邏輯，大家不要和我們這里說的業(yè)務(wù)邏輯相混淆。

為什么說除了Business代碼中有邏輯以外，其他地方不能有邏輯呢？我們每個部分分別分析：

如果service里面不是嚴格的順序調(diào)用，有很多分支，那么說明這個service做了兩件或者兩件以上的事情。必須把這個service分拆，確保每個service只做一件事情。因為如果不這么分拆的話，一旦這個service中的某各部分發(fā)生變動，其他的部分的執(zhí)行必定會受影響。而確定到底有哪些影響的溝通成本非常高，其他相關(guān)利益方?jīng)]有動力去配合，我們往往不會投入精力仔細評估。最后上線會出很多不可預(yù)料的問題，最終會導(dǎo)致?lián)p失用戶的利益，并且肯定會導(dǎo)致返工，損壞自己的利益。如果是有計算的邏輯的話，比如受益計算，訂單金額計算等，那么這部分應(yīng)該是Business代碼需要完成的，不能交給service代碼來實現(xiàn)。

Glue Code里面如果不是嚴格的順序調(diào)用，同理會和service一樣遇到同樣的問題。

Repository里面如果不是嚴格的順序調(diào)用，包括存儲訪問的代碼里面（比如SQL），會導(dǎo)致邏輯進入到存儲設(shè)備中。存儲設(shè)備的主要目的是拿來存儲的，一旦變成了邏輯計算的主體，就會導(dǎo)致存儲設(shè)備無法通過增加機器的方式橫向擴展長大。這個時候就沒有架構(gòu)了，只能換性能更好的機器，這個叫scale up。只有scale out才能算架構(gòu)。

以上都會導(dǎo)致架構(gòu)無法快速的橫向擴展和分拆，并且增加了修改的成本，這些是不符合開發(fā)人員以及業(yè)務(wù)的利益的。

這么做的好處有哪些呢？

Service、Glue Code、Repository里面的代碼是嚴格的順序調(diào)用，那么這些代碼只要做連通性測試即可，不需要單元測試。因為這些代碼都需要和很多上下文打交道，很難做單元測試。這樣才算是真正的組合。

Business不訪問任何上下文，不訪問任何具體的設(shè)備，所以這部分代碼是非常容易寫單元測試的，并且單元測試必須100%覆蓋。因為其他地方?jīng)]有業(yè)務(wù)邏輯，所以一旦有問題，就可以斷定是Model的問題，單元測試肯定可以發(fā)現(xiàn)。如果單元測試沒有發(fā)現(xiàn)問題，那么單元測試一定有問題。線上問題的模擬也就變得非常的簡單，單元測試也能夠得到進一步的補充。

Repository很容易按照存儲設(shè)備本身的最小訪問粒度來完成工作，比如DB，完全可以做到單表訪問。因為這個時候存儲設(shè)備只關(guān)心存取數(shù)據(jù)，完全和業(yè)務(wù)沒有關(guān)系。做表的分拆也是非常容易的事情，存儲設(shè)備通過增加機器就可以橫向擴展長大。很多人會擔心說，沒有了join，訪問DB的次數(shù)是不是更多了，會導(dǎo)致性能下降？按照現(xiàn)在網(wǎng)絡(luò)的條件，網(wǎng)絡(luò)訪問和Disk IO訪問的差距已經(jīng)不大了，合理的設(shè)計下，多訪問幾次DB并不會導(dǎo)致這個問題。另外如果多臺DB的話，還能通過并行加速訪問。

由于Service、Glue Code、Repository代碼簡單了，才可以讓我們的開發(fā)人員投入更多的時間研究業(yè)務(wù)，畢竟這部分才是軟件所真正服務(wù)的對象。

我們再來看一個實際的例子，如下圖所示：

Manager類實際就是Glue Code。有幾個注意點需要說明一下：

不能把Business Model當做數(shù)據(jù)對象來處理，Model關(guān)心的實際上是業(yè)務(wù)行為，數(shù)據(jù)只是是這些行為的結(jié)果。所以Glue Code需要把Model轉(zhuǎn)換為Entity，Entity和存儲設(shè)備里面的存儲粒度一一對應(yīng)。比如在DB中，每個Entity對應(yīng)一張表，并且跟著表的變化而變化，這樣就保證存儲的變更不會影響Model。同樣Service和用戶之間的數(shù)據(jù)交互，也是不會和Model之間相關(guān)的，確保用戶的需求變化，不會影響到Model。因為用戶的需求變化是最頻繁的，沒有邏輯，可以讓我快速的滿足業(yè)務(wù)的需求。

在Service這里，最好不要考慮代碼重用。因為當多個不同的角色訪問同一個接口，一旦某個角色的需求發(fā)生了變化，就會要求開發(fā)人員去修改。而這個修改往往會影響到其他的角色，需要這些角色一起配合來確定是否受影響，但是這些角色因為沒有需求，往往不會配合。這樣就給開發(fā)人員造成了很多不必要的溝通，成本是非常高的。最終都會導(dǎo)致線上Bug，影響最終的用戶。所以盡量給不同的角色不同的Service，避免重用，降低溝通成本。很多人會說這樣Service不就太多了嗎？這樣Service注冊，查找等管理需求就出現(xiàn)了，Service治理中心就是來解決這個問題的。因為Service里面沒有邏輯，所以開發(fā)和管理非常的簡單，可以快速應(yīng)對業(yè)務(wù)的變化。我們只有更快地變，更容易的變，才能更好地應(yīng)對變。

Business Model是必須要重用的，一旦發(fā)現(xiàn)重用出現(xiàn)問題，那么說明Business Model的識別出現(xiàn)了問題，這是一個我們要重新思考Model的信號。Business Model必須是一個完美的樹狀，如果不是，也說明Model的識別出了問題。

在實際操作中，Service、Glue Code、Repository不能有邏輯，實際上和很多人的觀念是沖突的，認為這個根本做不到。做到這一點需要很多的學(xué)習(xí)成本，但是一定可以做得到。當發(fā)現(xiàn)做不到的時候，可以斷定是業(yè)務(wù)的分析出了問題。比如不該合并的合并了，不該計算的計算了。這個問題一定有辦法解決的，做不到都是理由，無非是想早點把自己的工作結(jié)束罷了。雖然剛開始會比較困難，一旦把這個觀念變成自覺，開發(fā)的質(zhì)量和效率馬上就能高好幾個級別。

我的游泳教練曾和我說過這些話，我至今記憶猶新：“業(yè)余選手，越想從水里浮起來，就越想把頭抬起來，身體反而沉下去。只有克服恐懼，把頭往水里壓下去，身體才能夠從水里浮起來。真正專業(yè)的習(xí)慣往往是和我們?nèi)粘５男袨橄喾吹?/strong>”。

我們真正想快速的完成代碼工作，就要克服自己對時間的恐懼，真正的去研究業(yè)務(wù)的問題，相關(guān)stakeholder的利益，把這個變成我們的習(xí)慣。寫代碼的時候讓該出現(xiàn)邏輯的地方出現(xiàn)邏輯，讓不該出現(xiàn)的地方不能出現(xiàn)。一旦不該出現(xiàn)的地方出現(xiàn)了邏輯，那么要馬上意識到，這個地方是一個坑，這個問題一定和業(yè)務(wù)的分析不透徹有關(guān)系。

很多人可能會把這個做法和Martin Fowler曾經(jīng)提出過充血模型和貧血模型來比較，和Domain Driven Design來比較，其實沒有必要。這個分拆完全是從軟件所解決的問題，根據(jù)軟件架構(gòu)推導(dǎo)出來的，很多地方和兩位前輩的觀點是一致的，但是并不完全等同。

以上只是針對單一的Service部署單元的分析，擴展開去，對于其他的部署單元也是類似的。每個單元的下一級都可以認為是Repository，每個單元的上一級都可以認為是User。這些實踐在我自己的項目中都有用到，非常的有效，迭代的速度非常的快。很多人擔心Business Model建不好，其實沒關(guān)系，剛開始可以粗糙一點，后續(xù)可以慢慢的完善。這個架構(gòu)已經(jīng)隔離好了每個部分的變化對其他部分的影響，變化成本都在可控的范圍之內(nèi)。

架構(gòu)漫談（九）：理清技術(shù)、業(yè)務(wù)和架構(gòu)的關(guān)系

某天和朋友吃飯正好聊到這個話題。作為架構(gòu)師或者做技術(shù)的人，在開發(fā)軟件時，我們基本上就是在扮演上帝的角色：我們不但要創(chuàng)建出一個個的程序，還要讓這些程序能夠脫離我們在硬件上獨立運行，以便為這個程序所服務(wù)的群體提供服務(wù)。當這個程序出現(xiàn)問題甚至bug的時候，我們還得扮演牧師的角色去修復(fù)這些問題。這不正是一個程序的社會嗎？和人類社會的演變何其相似！那么我們自然也能夠拿人類演變的歷史來指導(dǎo)軟件開發(fā)工作，以避免再經(jīng)歷一次像人類演變發(fā)展那么痛苦的過程了。由此我們也可以看出，架構(gòu)師和程序員們都在扮演著多么重要的角色，如果還在解決自己的問題，怎么扮演好上帝這個角色？

在軟件設(shè)計開發(fā)的過程中經(jīng)常會看到，很多所謂的架構(gòu)討論實際上只是在討論某種技術(shù)。在很多人的概念里面，架構(gòu)和技術(shù)實際上是等同的。學(xué)會了幾種技術(shù)，就認為自己是架構(gòu)師了，甚至是學(xué)習(xí)的技術(shù)越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術(shù)都是為了解決某種問題而存在的，學(xué)會了技術(shù)，并不代表自己能夠解決問題，這一點非常的重要。學(xué)會的技術(shù)的多少，所帶來的差別只是自己解決問題的手段多了罷了。但是手段多了就一定是好事嗎？很多時候，學(xué)習(xí)的技術(shù)越多，越不知道采用哪種技術(shù)好，所謂“亂花漸欲迷人眼"。

還有另一種很普遍的觀點：技術(shù)人普遍看不起業(yè)務(wù)，認為技術(shù)更高端，而業(yè)務(wù)太低端，并且業(yè)務(wù)往往喜歡給技術(shù)挖坑。業(yè)務(wù)則覺得技術(shù)眼光高，但是實際解決不了問題，總是理解有偏差，但是又無可奈何，因為自己不會。

我們應(yīng)該怎么處理業(yè)務(wù)、技術(shù)還有架構(gòu)的關(guān)系。

什么是技術(shù)

當我們一無所有，或者什么都不會的時候，這個時候?qū)嶋H上是沒有技術(shù)的。就好比人類在最早期，什么都得用自己的雙手來干活。一旦我們在日常生活中無意間發(fā)現(xiàn)某些規(guī)律的時候，我們就可以通過創(chuàng)造條件，讓這個規(guī)律重復(fù)的發(fā)生。通過人為創(chuàng)造條件，讓指定的規(guī)律按照人類的意愿發(fā)生，這就是技術(shù)。

比如取火，最早人類只能靠打雷等自然現(xiàn)象產(chǎn)生火。取火其實就是一個業(yè)務(wù)目標，要解決的是人類自己的問題，這就是業(yè)務(wù)，實際就是人類的利益。這個時候人類沒有生火的技術(shù)，只能靠不斷的加木材，保持火不熄滅。后來人們發(fā)現(xiàn)了鉆木取火：只要用一個干的木棍，在另一個干木表面快速的轉(zhuǎn)動，就可以生火。這個辦法讓人類可以自行創(chuàng)造火源，就產(chǎn)生了鉆木取火的技術(shù)。

但是雙手快速轉(zhuǎn)動木棍鉆木取火，并不是所有人都能夠做得到的，需要很多力量和速度，對人的要求太高。為了解決快速轉(zhuǎn)動的問題，就有人采用弓弦來提升木棍轉(zhuǎn)動的速度。

也就是說：

業(yè)務(wù)目標是為了取火，鉆木取火這個技術(shù)的出現(xiàn)解決了這個問題。

鉆木取火的效率不高，影響了業(yè)務(wù)（取火）的效率，就有了進一步改進的動機，改進轉(zhuǎn)動木棍的方式，產(chǎn)生了弓弦轉(zhuǎn)動木棍的技術(shù)。

技術(shù)與架構(gòu)，以及與業(yè)務(wù)之間的關(guān)系

技術(shù)總是在人類解決對業(yè)務(wù)的要求不斷提高的情況下產(chǎn)生，目的也是為了獲取更大更好的利益。所以：

技術(shù)是為了解決業(yè)務(wù)的問題而產(chǎn)生的，沒有了業(yè)務(wù)，技術(shù)就沒有了存在的前提。

有了更好的技術(shù)，效率更差的技術(shù)，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求——也就是業(yè)務(wù)。有人會問，不用鉆木取火了，但是弓弦加速轉(zhuǎn)動木棍還可以用啊？沒錯，因為弓弦轉(zhuǎn)動木棍這個技術(shù)，不是來生火的，是用來加速木棍轉(zhuǎn)動的，所解決的問題不一樣。但是兩種不同的技術(shù)，合理結(jié)合起來，會更好更有效率的解決業(yè)務(wù)問題。

所以技術(shù)與技術(shù)之間，有兩種關(guān)系：

在解決同一個業(yè)務(wù)問題的前提下，更高效，更低成本的技術(shù)，會淘汰低效，高成本的技術(shù)。這是人類利益訴求所決定的。

一般剛開始解決根本問題的技術(shù)（鉆木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術(shù)才是業(yè)務(wù)的enabler）。然后就會有提高效率的需求出現(xiàn)，要求改進這個技術(shù)。這個技術(shù)的低效率部分就會被其他人（或者技術(shù)發(fā)明人自己）加以改進，這部分就會形成新的技術(shù)。

當關(guān)系2發(fā)生的時候，這個地方必定會形成一個切分，新技術(shù)會通過某種方式和原有的技術(shù)連接在一起形成一個整體，讓這個新的技術(shù)可以和原有技術(shù)共同工作，使得原有的技術(shù)可以用更高的效率解決問題。因為要解決的主要問題（生火）并沒有發(fā)生改變，分拆所形成的是一個樹狀的結(jié)構(gòu)。

按照前面的架構(gòu)定義，這個時候其實已經(jīng)產(chǎn)生了架構(gòu)。也就是說，一般是先有技術(shù)，才會有架構(gòu)。這些其他技術(shù)（弓弦拉動木棍），是從直接解決問題的初始主要技術(shù)中分拆出來形成的，并通過樹狀結(jié)構(gòu)和主要技術(shù)（鉆木取火）組合在一起。在解決主要問題（生火）之后，再開始逐漸的分拆為更為細粒度的技術(shù)（弓弦轉(zhuǎn)木棍）。

而這個細粒度的技術(shù)（弓弦轉(zhuǎn)動木棍）往往不會和業(yè)務(wù)的主要目標（生火）發(fā)生直接的關(guān)系。不同的技術(shù)，通過樹狀結(jié)構(gòu)，組合在一起，形成了一個完整的架構(gòu)解決方案，共同完成業(yè)務(wù)的目標。這就是技術(shù)，業(yè)務(wù)和架構(gòu)之間的關(guān)系。很多人把這個過程稱為架構(gòu)的進化，我更愿意把這個過程稱為技術(shù)的進步所導(dǎo)致的新的架構(gòu)分拆，因為這個過程內(nèi)在的動力，更多的是來自技術(shù)對業(yè)務(wù)問題的解決。

技術(shù)人員和業(yè)務(wù)人員的關(guān)系

為什么技術(shù)人員總是和業(yè)務(wù)人員發(fā)生沖突呢？這是因為技術(shù)人員很多時候關(guān)心的技術(shù)，和業(yè)務(wù)的主要目標往往不是直接對應(yīng)的，業(yè)務(wù)也是負責某一部分的業(yè)務(wù)，也不是和業(yè)務(wù)的主要目標直接對應(yīng)的，都是樹的分支節(jié)點（上文已經(jīng)解釋了為何會發(fā)生這種情況）。只有直接解決業(yè)務(wù)問題的那個技術(shù)（或業(yè)務(wù)）—— 樹的根節(jié)點 —— 會和業(yè)務(wù)直接相關(guān)。所以一旦產(chǎn)生沖突，一般必須兩個根節(jié)點（一般都是領(lǐng)導(dǎo)）碰面才能解決問題，就是這個原因——他們都知道業(yè)務(wù)主要目標。這也是為什么下層無法理解上層，而上層都喜歡下軍令狀，要求下層執(zhí)行。人只有盡量去理解上層的問題才能做下層的分拆。

在軟件行業(yè)，這個根節(jié)點技術(shù)就是軟件。這也是為什么架構(gòu)師要認識什么叫軟件，軟件解決誰的問題，什么問題，軟件本身又是怎么分拆的，才能夠更好的組合不同的技術(shù)，完成業(yè)務(wù)的目標。而軟件里面和業(yè)務(wù)直接相關(guān)的，只有Business Domain這一部分。

用人來打比方，Business Domain相當于人的大腦，而Service，Repository，Glue Code等部分所采用的技術(shù)，全部都是計算機自己領(lǐng)域的技術(shù)，都是為了能夠讓程序跑起來，相當于人的四肢。我們大部分開發(fā)人員的工作主要專注于四肢部分。我們真正應(yīng)該投入的是大腦部分。因為大腦能夠決定四肢長什么樣，而不是反過來。很多架構(gòu)師、技術(shù)人員主要專注于計算機相關(guān)的技術(shù)，忽略了業(yè)務(wù)本身，甚至看不起業(yè)務(wù)，這也是為什么技術(shù)總是和業(yè)務(wù)沖突的原因。

架構(gòu)師應(yīng)該承擔起解決業(yè)務(wù)問題的這個角色來，專注于Business Domain和軟件本身的架構(gòu)，讓技術(shù)人員致力于為業(yè)務(wù)在計算機中跑起來而努力。只有把這兩者很好的結(jié)合起來，才能更好地完成業(yè)務(wù)的目標，才會讓軟件更好地服務(wù)于大家。最終一定會得到一個很好的軟件架構(gòu)，令軟件開發(fā)團隊和業(yè)務(wù)部門都能夠很好地開展工作并降低成本。

重新發(fā)明輪子

當現(xiàn)有已經(jīng)存在很多技術(shù)，而這些技術(shù)卻和我們所要解決的問題并不是那么直接對應(yīng)的時候，我們就需要有意識的組織和識別不同的技術(shù)，來實現(xiàn)業(yè)務(wù)的目標。這個時候組織的方式有很多種，其中成本最低的方法就是按照要達成的目的和當前的問題，從上到下進行架構(gòu)分拆。分拆出來的更細粒度的問題，分解到不同的人來進行解決，就形成了業(yè)務(wù)架構(gòu)和組織架構(gòu)。解決這些問題就需要組合很多不同的技術(shù)，那么應(yīng)該采用哪些技術(shù)？還是自己重頭實現(xiàn)一個？自己實現(xiàn)一個——這就是很多人所謂的重新發(fā)明輪子。以下試著分析一下：

當技術(shù)所解決的問題和分拆出來要解決的問題，完全匹配的時候，這是最完美的。比如需要提供web要訪問的service，很多MVC的framework就可以很好的滿足這一點。而這個時候如果非要自己實現(xiàn)一個，很有可能就是重新發(fā)明輪子。

當技術(shù)所提供的能力遠遠超過需要解決的問題時，往往掌握技術(shù)和維護技術(shù)會成為瓶頸。因為越復(fù)雜的技術(shù)，成本越高。如果自己實現(xiàn)一個僅僅是解決當前問題的方案，可能成本反而更低。這也是為什么很多大型的互聯(lián)網(wǎng)公司不斷地開源出來自己的技術(shù)的原因。而這些技術(shù)對于我們來說是否適用？他們原本是用來解決誰的問題的？什么問題？如果不清楚這些，就冒然采用，可能會導(dǎo)致更高的成本。

當技術(shù)所提供的能力和我們所要解決的問題部分匹配時，還是要看成本。比如當我們需要一個錘子的時候，手邊正好沒有，但是卻有一只高跟鞋，勉強也可以替代錘子。但是長期來看，這么用不劃算，因為高跟鞋的價格比錘子高很多，耐用性差很多，維護成本也高很多。

所以，準確識別采用什么技術(shù)的能力，也是架構(gòu)師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。

（部分內(nèi)容來源網(wǎng)絡(luò)，如有侵權(quán)請聯(lián)系刪除）