架构漫谈（一）：什么是架构？ -王概凯 - 转
架構漫談（一）：什么是架構？
架構漫談是由資深架構師王概凱Kevin執(zhí)筆的系列專欄，專欄將會以Kevin的架構經(jīng)驗為基礎，逐步討論什么是架構、怎樣做好架構、軟件架構如何落地、如何寫好程序等問題。專欄的目的是希望能拋出一些觀點，并引發(fā)大家思考，如果你有感觸或者新的感悟，歡迎聯(lián)系專欄負責人Gary（微信greenguolei）深聊。
本文是漫談架構專欄的第一篇，作者將會通過類比的方式來介紹什么是架構以及為什么會產(chǎn)生架構。
緣起
一直以來，在軟件行業(yè)，對于什么是架構，都有很多的爭論，每個人都有自己的理解。甚至于很多架構師一說架構，就開始談論什么應用架構、硬件架構、數(shù)據(jù)架構等等。我曾經(jīng)也到處尋找過架構的定義，請教過很多人，結果發(fā)現(xiàn)，沒有大家都認可的定義。套用一句關于big data流行的笑話，放在架構上也適用：
Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。
事實上，架構在軟件發(fā)明時的N多年以前，就已經(jīng)存在了，這個詞最早是跟隨著建筑出現(xiàn)的。所以，我覺得有必要從源頭開始，把架構這個概念先討論清楚，只有這樣，軟件行業(yè)架構的討論才有意義。
什么是架構？
架構的英文是Architecture，在Wikipedia上，架構是這樣定義的：
Architecture (Latin architectura, from the Greek ?ρχιτ?κτων arkhitekton"architect"， from ?ρχι- "chief" and τ?κτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。
從這個定義上看，架構好像是一個過程，也不是很清晰。為了講清楚這個問題，我們先來看看為什么會產(chǎn)生架構。
為什么會產(chǎn)生架構？
想象一下，在最早期，每個人都完全獨立生活，衣、食、住、行等等全部都自己搞定，整個人類都是獨立的個體，不相往來。為了解決人類的延續(xù)的問題，自然而然就有男女群居出現(xiàn)，這個時候就出現(xiàn)了分工了，男性和女性所做的事情就會有一定的分工，可是人每天生活的基本需求沒有發(fā)生變化，還是衣食住行等生活必須品。
但是一旦多人分工配合作為生存的整體，力量就顯得強大多了，所以也自然的形成了族群：有些人種田厲害，有些人制作工具厲害，有些地方適合產(chǎn)出糧食，有些地方適合產(chǎn)出棉花等，就自然形成了人的分群，地域的分群。當分工發(fā)生后，實際上每個人的生產(chǎn)力都得到了提高，因為做的都是每個人擅長的事情。
整個人群的生產(chǎn)力和抵抗環(huán)境的能力都得到了增強。為什么呢？因為每個人的能力和時間都是有限的，并且因為人的結構的限制，人同時只能專心做好一件事情，這樣不得已就導致了分工的產(chǎn)生。既然分工發(fā)生了，原來由一個人干生存所必需的所有的事情，就變成了很多不同分工的角色合作完成這些事情，這些人必須要通過某些機制合在一起，讓每個人完成生存所必需的事情，這實際上也導致了交易的發(fā)生（交易這部分就不在這里展開了，有機會再討論）。
在每個人都必須自己完成所有生活必須品的生產(chǎn)的時候，是沒有架構的（當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產(chǎn)生架構的）。一旦產(chǎn)生的分工，就把所有的事情，切分成由不同角色的人來完成，最后再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的事情，并具備一定的交易能力即可。
這實際上就形成了社會的架構。那么怎么定義架構呢？以上面這個例子為例，把一個整體（完成人類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，并通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為一個整體，并完成這個整體所需要的所有活動，這就是架構。由以上的例子，也可以歸納出架構產(chǎn)生的動力：
必須由人執(zhí)行的工作（不需要人介入，就意味著不需要改造，也就不需要架構了）
每個人的能力有限（每個人都有自己的強項，個人的產(chǎn)出受限于最短板，并且由于人的結構限制，同時只能專注于做好一件事情，比如雖然有兩只眼睛，但是只能同時專注于一件事物，有兩只手，無法同時做不同的事情。ps. 雖然有少部分人可以左手畫圓右手畫框，但是不是普遍現(xiàn)象）
每個人的時間有限（為了減少時間的投入，必然會導致把工作分解出去，給擅長于這些工作的角色來完成，見2，從而縮短時間）
人對目標系統(tǒng)有更高的要求（如果滿足于現(xiàn)狀，也就不需要進行架構了）
目標系統(tǒng)的復雜性使得單個人完成這個系統(tǒng)，滿足條件2，3（如果個人就可以完成系統(tǒng)的提高，也不需要別的人參與，也就不需要架構的涉及，只是工匠，并且一般這個工作對時間的要求也不迫切。當足夠熟練之后，也會有一定的架構思考，但考慮更多的是如何提高質(zhì)量，提高個人的時間效率）
有人可能會挑戰(zhàn)說，如果一個人對目標系統(tǒng)進行分解，比如某人建一棟房子，自己采購材料，自己搭建，難道也不算架構嘛？如果對于時間不敏感的話，是會出現(xiàn)這個情況的，但是在這種情況下，并不必然導致架構的發(fā)生。如果有足夠的自覺，以及足夠的熟練的話，也會產(chǎn)生架構的思考，因為這樣對于提高生產(chǎn)力是有幫助的，可以縮短建造的時間，并會提高房子的質(zhì)量。事實上建筑的架構就是在長期進行這些活動后，積累下來的實踐。
當這5個條件同時成立，一定會產(chǎn)生架構。從這個層面上來說，架構是人類發(fā)展過程中，由懵懵懂懂的，被動的去認識這個世界，變成主動的去認識，并以更高的效率去改造這個世界的方法。以下我們再拿建筑來舉例加強一下理解。
最開始人類是住在山洞里，住在樹上的，主要是為了躲避其他猛獸的攻擊，以及減少自然環(huán)境的變化，對人類生存的挑戰(zhàn)。為了完成這些目標，人類開始學會在平地上用樹木和樹葉來建立隔離空間的設施，這就是建筑的開始。但是完全隔離也有很多壞處，慢慢就產(chǎn)生了門窗等設施。
建筑的本質(zhì)就是從自然環(huán)境中，劃出一塊獨占的空間，但是仍然能夠通過門窗等和自然環(huán)境保持溝通。這個時候架構就已經(jīng)開始了。對地球上的空間進行切分，并通過門窗，地基等，保持和地球以及空間的有機的溝通。當人類開始學會用火之后，茅棚里面自然而然慢慢就會被切分為兩部分，一部分用來燒飯，一部分用來生活。當人的排泄慢慢移入到室內(nèi)后，洗手間也就慢慢的出現(xiàn)了。這就是建筑內(nèi)部的空間切分。
這個時候人們對建筑的需求也就慢慢的越來越多，空間的切分也會變成很多種，組合的方式也會有很多種，比如每個人住的房子，群居所產(chǎn)生的宗教性質(zhì)的房子，集體活動的房子等等。這個時候人們就開始有意識的去設計房子，架構師就慢慢的出現(xiàn)了。一切都是為了滿足人的越來越高的需求，提升質(zhì)量，減少時間，更有效率的切分空間，并且讓空間之間更加有機的進行溝通。這就是建筑的架構以及建筑的架構的演變。
總結一下，什么是架構，就是：
同樣這個思考可以展開到其他的行業(yè)，比如企業(yè)的架構，國家的架構，組織架構，音樂架構，色彩架構，軟件架構等等。套用三國演義的一句話，合久必分，分久必合。架構實際上就是指人們根據(jù)自己對世界的認識，為解決某個問題，主動地、有目的地去識別問題，并進行分解、合并，解決這個問題的實踐活動。架構的產(chǎn)出物，自然就是對問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合并的原則以及理由，以及拆分，拆分出來的各個部分和合并所對應的角色和所需要的核心能力等。
架構漫談（二）：認識概念是理解架構的基礎
在前一篇文章中，我們討論了什么是架構。事實上，這些基礎概念對于做架構是非常重要的，大部分人對于每天都習以為常的概念，都自以為明白了，但實際上都是下意識的，并不是主動的認識。比如說“什么是桌子？”，做培訓的時候，我經(jīng)常拿這個例子來問大家，回答千奇百怪。這實際上就導致了做架構的時候，不同角色的溝通會出很多問題，那么結果也就可想而知了。
如前一篇所說，架構實際上解決的是人的問題，而概念是人認識這個世界的基礎，自然概念的認識就非常的重要。這篇文章嘗試討論一下，如何去認識概念。當然這篇不是語言學的文章，我這里所討論的，和語言學可能不太一樣，如果大家對語言學感興趣，也可以去參考一下。
首先我要先聲明一下，這一系列的文章，都是以人的認識為主體去討論的，解決的都是人的問題，任何沒有具體申明的部分，都隱含這一背景，以免大家誤解。
概念也屬于人認識這個世界并用來溝通的手段，包括“概念”這個概念，也是一樣的。在古代，不叫“概念”，稱之為“名相”。
何為相？
一般我們認為：看到一個東西，比方說杯子，“杯子”就是一個名字，指代的看到的東西就是相，就是事物的相狀。我們一聽到“杯子”這個詞，腦海里就會浮現(xiàn)出一個杯子的形象。而“杯子”這個詞，是用來指代的是這個相狀的，叫做名。合起來就叫做“名相”。
可是當我們把杯子打碎了的時候，我們還會稱這個碎了的東西叫杯子嗎？ 肯定不會，一般會叫“碎瓦片”，如果我們把碎瓦片磨碎了呢，名字又變了，叫做“沙子”。這就奇怪了，同樣一個東西，怎么會變出這么多的名字出來？
那究竟什么才是相？
實際上“相“表達的不是一個具體的東西，如上面所提的一個瓷器杯子，并不是指這個瓷器，而是這個瓷器所起的一個作用：一手可握，敞口（一般不超過底的大小，太大口就叫碗了），并且內(nèi)部有一個空間可乘東西的這么一個作用。并不是指這個瓷器本身。這也是為什么我們從電視上看到一個人拿杯子的時候，我們知道這個是杯子。但是實際上我們看到的都是光影而已。所以說相實際上代表的是這個作用，并不是具體的某個東西，而名是用來標識這個作用的，用來交流的。
為何需要這個作用？
這個作用其實是為了解決“人需要一個可單手持握，但是希望避免直接接觸所盛物體”這個問題。
所以說，每個概念實際上所解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了一個名字，這個名字就是對應的某個特定的概念。對于概念這個詞本身，為了統(tǒng)一指代這些名字，我們稱起這類作用的名字稱為“概念”。我們上次討論的“架構”也是是同樣的一個特定概念，這里不再詳述。同樣，什么是“建筑”？ “建筑”實際上解決的就是“人需要獨占的空間，并還能夠比較流暢的和外部世界溝通”的問題。
再拿前面的“桌子”來舉例，什么叫“桌子”？ 很多人回答，四條腿，或者說有腿，有一個平面，等等，柜子不也是這樣嗎？為什么我們看到柜子，不會認為是桌子呢？即使我們放在柜子上吃飯，我們看到仍然會問，為什么在柜子上吃飯？ 不會叫桌子。如果明白了上面的道理，就很簡單了，桌子實際上是為了解決人坐在椅子上，手還能夠支撐在一個平面上繼續(xù)開展活動的問題，一般會和椅子配對出現(xiàn)。坐在椅子上工作，對著柜子有一個很嚴重的問題——不知道大家試過沒有——就是腿無法展開的問題。當這么坐著超過半小時就知道是什么痛苦了。所以桌子的平面下方一定會有一個足夠容納膝部和小腿的空間，來解決這個問題。解決了這些問題的裝置，才能稱之為桌子。
類似也可以定義出來椅子，由此可見，桌子和椅子的高度也是有限定的，都是是解決人的問題，要符合人的身高：椅子的高度和深度，必須符合小腿和大腿的長度；椅背的高度要配合脊柱的高度；桌子的高度要配合小腿和脊柱的高度之和；成人和小孩的自然也就有區(qū)別了。這又變成生理學了，事實上要做好桌子和椅子，必須要理解人的生理結構，才能正確的理解桌子和椅子的概念。
同理，為何我們可以在不同的語言間進行翻譯，是因為雖然語言不同，但是人類所面臨的的問題是一樣的，所使用的名不同而已。對于不同的動物之間的翻譯也是同理。
關于抽象
在討論桌子這個概念的過程中，很多人會提出抽象這個概念，認為定義桌子實際上就是抽象的一個過程。這里，我覺得有必要要澄清一下抽象這個概念，我認為這個里面有誤解。我注意到，在做架構師的群體中，不談抽象好像就不是一個合格的架構師。
抽象這個詞代表的含義，實際上是把不同的概念的相似的部分合并在一起，形成一個新的概念。這個里面問題很多：首先“相似的部分”在不同的人看來，并不一定那么相似；其次，抽象之后形成的是一個新的概念，和原來那個概念并不一樣，所解決的問題也不一樣。所以我們不能用抽象來定義一個事物，抽象實際上是一個分類的過程，完全是另一碼事。再舉一個例子，杯子和容器，很多人認為容器是杯子的抽象，但是實際上杯子是杯子，容器是容器，它們所解決的問題是不一樣的。當我們需要解決裝東西的問題的時候，會說容器；當我們需要解決單手持握要裝東西的時候，會說要一個杯子。
回過頭來，根據(jù)架構的定義，要做好架構所首先必須具備的能力，就是能夠正確的認識概念，能夠發(fā)現(xiàn)概念背后所代表的問題，進而才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。事實上，這一能力，在任何一個領域都是適用的，比如我們?nèi)绻胍獙W習一項新的技術，如Hibernate、Spring、PhotoShop、WWW、Internet等等，如果知道這些概念所要解決的問題，學習這些新的技術或者概念就會如虎添翼，快速的入手；學習一個新的領域，也會非常的快速有效；使用這些概念來解釋問題，甚至發(fā)明新的概念都是很容易的事。為什么強調(diào)這個呢，因為做架構的時候，很多時候都是在一個新的領域解決問題，必須要快速進入并掌握這個領域，然后才能夠正確的解決問題。
以上通過幾個例子，討論了一下認識概念的誤區(qū)，如何有效的去認識概念，明白概念背后的含義，以及如何利用對概念的理解，快速的進行學習。掌握了這些原則，會有利于幫助我們在架構階段，快速的識別和定位問題。
下一篇我們會來討論一下，如何快速的定位和識別問題，這是架構的起始。
架構漫談（三）：如何做好架構之識別問題
按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那么問題就已經(jīng)解決80%了。這個能力基本上就決定了架構師的水平。
那么面對問題有哪些困難呢?
我們先看一則笑話。女主人公：老公，把袋子里的土豆切一半下鍋。結果老公是把袋子里的每個土豆都削了一半，然后下鍋。
當然很多人會說，這個是溝通問題，然后一笑了之。其實，出現(xiàn)這個現(xiàn)象是由于我們大部分時候過于關注解決問題，急于完成自己的工作，而不關心“真正的問題是什么”而造成的。當我們?nèi)ソ鉀Q一個問題的時候，一定要先把問題搞清楚。這也是我為什么要單獨寫一篇文章講這個的原因。去看看軟件開發(fā)工作者的時間分配也可以看出，大家大部分時間花在討論解決方案和實現(xiàn)的細節(jié)上，基本都不會花時間去想“問題是什么”。或者即使想了一點點，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什么的工程師，才可能會真正的成長為架構師
以這個笑話為例，看看在我們處理問題的時候，都會犯什么樣的錯誤：
那么如何識別問題呢?
所有的概念基本都有一個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。
以上面切土豆的例子來分析：
每個人都是優(yōu)先處理自己的問題，自然就選擇了2，完成了這個任務。這也是大部分軟件工程師處理的方式，以自己認為對的方式完成自己的問題，沒什么不對啊，也難怪能得到我們的共鳴。這個里面犯的錯誤是什么呢?
女主人公提出的實際上是解決方案，而不是燒土豆這個問題本身。女主人當時執(zhí)行這個解決方案可能有困難，就把執(zhí)行解決方案作為一個任務，委托給了男主人。
男主人得到了一個任務，盡心盡職地把這個任務完成了。
最后的結果是什么呢，每個人都做了很多工作，每個人都認為自己做的是對的，因此沒有一個人對結果滿意。因為真正的問題沒有被發(fā)現(xiàn)，自然也就沒有被解決，那么后續(xù)還得收拾殘局，還要繼續(xù)解決問題。事實上自己的工作并沒有完成，反而更多了。把原因歸結為溝通問題也是可以的，但對于解決問題似乎并沒有太多的幫助。因為要改進溝通，這也是一個大問題。搞明白目標問題“是誰的問題，是什么問題”，當然也是需要溝通的。為了幫助自己更快的搞明白，首先要做的事是問正確的問題。架構師應該問的第一個正確的問題就是：目標問題是誰的問題。
當我們處理問題的時候，如果發(fā)現(xiàn)自己正在致力于把自己的工作完成，要馬上警惕起來，因為這樣下去會演變成沒有ownership的工作態(tài)度。在面對概念的時候，也會不求甚解，最終會導致沒有真正的理解概念。
作為軟件工程師或者架構師，我們大部分時候是要去解決別人的問題，“別人”是誰，是值得好好思考的。在這個故事里面，男主人要解決的，實際上是這個家庭晚餐需要吃土豆的問題，目標問題的主體實際上是這個家庭的成員。
明白了問題的主體，這個主體就自然會帶來很多邊界約束，比如土豆是要吃的，要給人吃的，而且還是要給自己的家人吃的。“切土豆下鍋”這個問題，因為識別了問題的主體，自然而然的就附帶了這么多的信息。后續(xù)如何煮，是否放高壓鍋煮，放多少水，煮多長時間等等，就自然而然能夠問出來其他問題來了，說不定還能夠識別出來，女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題。可以想象，這樣下去最后的結果一定是大家都滿意的，因為真正的問題解決了。只有真正明白了是誰的問題，才能夠真正地完成自己的任務，真正地把自己的問題解決掉，而不是反過來。
由上面的分析可以看出，找出問題的主體，是做架構的首要問題。這也是我一再強調(diào)的，我們要解決的問題，一定都是人的問題。更進一步，架構師要解決的，基本都是別人的問題，不是自己的問題。再進一步，我們一定要明白，任何找上架構師的問題，絕對都不是真正的問題。為什么呢? 因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發(fā)現(xiàn)問題永遠都比解決問題來的更加重要。
當問題的主體離架構師越遠，就會讓找出問題主體的過程越加困難，我們再舉一個軟件行業(yè)比較熟悉的例子：用戶給產(chǎn)品經(jīng)理提出要求，想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰，是用戶還是設計師還是施工隊? 如果產(chǎn)品經(jīng)理當成是自己的問題，那么毫無疑問就給了錘子了。
我們需要識別：用戶究竟是二傳手，還是問題的真正主體。如果是設計師，那么問題的邊界就變成了設計師的問題；如果是施工隊，那么問題就變成了施工隊的問題；如果是用戶，那么就要看看用戶到底有什么困難，絕對不是要一個錘子這么簡單。這也說明了，問題的主體對問題的邊界確定有多么的重要。
當明白了問題的主體，我們才可能真正的認識問題是什么。因為問題的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。一旦確定了主體，剩下的就是去搞明白主體有哪些問題。這個就比較直接了，常用的方式就是直接面對主體進行訪談，深入到主體的工作生活當中，體驗并感受這些問題，甚至通過數(shù)據(jù)的反饋來定位問題。這個大家就比較熟悉了，我就不展開了。
一般來說，從問題暴露的點，一點點去溯源查找，一定會找出來誰的問題，以及是什么問題。最壞情況就是當我們時間或者能力有限，實在是無法定位出是誰的問題的時候，比如系統(tǒng)出故障，也就意味著我們無法根本解決問題。這時最好的辦法就是去降低問題發(fā)生所帶來的成本，盡量去隔離問題影響的范圍。給我留出時間和空間去識別真正的問題。
總結一下，要正確的認識問題，需要問兩個問題：
當?shù)玫降幕卮鹗侵е嵛岬臅r候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經(jīng)驗，問題1會花比較多的時間，也是支支吾吾最多的地方，因為架構要解決的問題都是人的問題。但是一旦確定了答案，問題2就會變得非常容易。可以這樣說，架構師的能力大部分會體現(xiàn)在問題1的識別上。
架構漫談（四）：如何做好架構之架構切分
前一篇已經(jīng)講了如何識別問題。在識別出是誰的問題之后，會發(fā)現(xiàn)，在大部分情況下，問題都迎刃而解，不需要做額外的動作。很多時候問題的產(chǎn)生都是因為溝通的誤解，或者主觀上有很多不必要的利益訴求導致的。但是總還有一部分確實是有問題的，需要做調(diào)整，那么就必須要有所動作，做相應的調(diào)整。這個調(diào)整就是架構的切分。
切分就是利益的調(diào)整
我們要非常的清楚，所有的切分調(diào)整，都是對相關人的利益的調(diào)整。為什么這么說呢，因為維護自己的利益，是每個人的本性，是在骨子里面的，我們不能逃避這一點。我們以第一篇文章里面的例子為例來做解釋。
我們已經(jīng)知道，隨著社會的發(fā)展，分工是必然的，為什么呢? 這個背后的動力就是每個人自己的利益。每個人都希望能夠把自己的利益最大化，比如：生活的更舒適，更輕松，更安全，占用并享有更多的東西。但是每個人的能力和時間都非常的有限，不可能什么都懂，所以自然需要舍掉一些自己不擅長的東西，用自己擅長的東西去換取別人擅長的東西。
對比一個人干所有的事情，結果就是大家都能夠得到更多，當然也產(chǎn)生了一個互相依賴的社會，互相誰都離不開誰。這就是自然而然而產(chǎn)生的架構切分，背后的原動力就是人們對自己利益的渴望。人們對自己利益的渴望也是推動社會物質(zhì)發(fā)展的原動力。
在這個模式下，比較有意思的是，每個人必須要舍掉自己的東西，才能夠得到更多的東西。有些人不愿意和別人進行交換，不想去依賴于別人，這些人的生活就很明顯的差很多，也辛苦很多，自然而然的就被社會淘汰了。如果需要在這個社會上立足，判斷標準就變成了：如何給這個社會提供更好更有質(zhì)量的服務。提供的更好更多的服務，自然就能夠換取更多更好的生活必需品。實際上這就是我們做人的道理。
為什么需要切分？
當人們認識到要主動的去切分一個系統(tǒng)的時候，毫無疑問，我們不能忘掉利益這個原動力。所有的切分決策都不能夠違背這一點，這是大方向。結合前一篇“識別問題”，一旦確定了問題的主體，那么系統(tǒng)的利益相關人（用現(xiàn)代管理學語言叫：stakeholder）就確定了下來。所發(fā)現(xiàn)的問題，會有幾種情況：
切分的原則
情況1是切分的原因，情況2是切分不合理而導致的新的問題，最終還是要回到情況1。對于情況1，本質(zhì)上都是時間上的負載。因為每個人的時間是有限的，怎么在有限的時間內(nèi)做出更多的事情？那么只有把時間上連續(xù)的動作，切分成時間上可以并行的動作，在空間上橫向擴展。所以切分就要有幾個原則：
必須在連續(xù)時間內(nèi)發(fā)生的一個活動，不能切分。比如孕婦懷孕，必須要10月懷胎，不能夠切成10個人一個月完成。
切分出來的部分的負責人，對這個部分的權利和義務必須是對等的。比方說媽媽10月懷胎，媽媽有權利處置小孩的出生和撫養(yǎng)，同樣也對小孩的出生和撫養(yǎng)負責。為什么必須是這樣呢? 因為如果權利和義務是不對等的話，會傷害每個個體的利益，分出來執(zhí)行的效率會比沒有分出來還要低，實際上也損害了整體的利益，這違背了提升整體利益的初衷。
切分出來的部分，不應該超出一個自然人的負載。當然對于每個人的能力不同，負載能力也不一樣，需要不斷的根據(jù)實際情況調(diào)整，這實際上就是運營。
切分是內(nèi)部活動，內(nèi)部無任怎么切，對整個系統(tǒng)的外部應該是透明的。如果因為切分導致整個系統(tǒng)解決的問題發(fā)生了變化，那么這個變化不屬于架構的活動。當然很多時候當我們把問題分析的比較清楚的時候，整個系統(tǒng)的邊界會進一步的完善，這就會形成螺旋式的進化。但這不屬于架構所應該解決的問題。進化的發(fā)生，也會導致新的架構的切分。
原則2是確保我們不能違反人性，因為維護自己的利益，是每個人的本性。只有權利和義務對等才能做到這一點。從原則2的也可以推理，所有的架構分拆，都應該是形成樹狀的結果，不應該變成有向圖，更不應該是無向圖。很多人一談架構，必談分層，但是基本上都沒意識到，是因為把一個整體分拆為了一棵樹，因為有了樹，才有層。
從某種意義上來說，談架構就是談分層，似乎也沒有錯，但是還是知道為什么比較好。從根節(jié)點下來，深度相同的是同一層。這個是數(shù)學概念，我就不展開了，感興趣可以去復習一下數(shù)學。
同樣我們看一個組織架構，也可以做一個粗略的判斷，如果一個企業(yè)的組織架構出現(xiàn)了“圖”，比方說多線匯報，一定是對stakeholder的利益分析出現(xiàn)了問題，這就會導致問題2的發(fā)生。問題2一旦出現(xiàn)，我們必須馬上要意識到，如果這個問題持續(xù)時間長，會極大的降低企業(yè)的運作效率，對相關stakeholder的利益都是非常不利的，同樣對于企業(yè)的利益也是不利的。必須快速調(diào)整相關stakeholder的職責，使得企業(yè)的組織架構成為一個完美的樹狀，并且使得樹的層數(shù)達到盡可能的低。只有平衡樹可以比較好的達到這個效果。
當然如果某個節(jié)點的能力很強，也可以達到減小樹的高度的結果。技術的提升，也是可以提升每個節(jié)點的能力，降低樹的層數(shù)。很多管理學都在討論如何降低組織架構的層數(shù)，使得管理能夠扁平化，原因就在于此，這里就不展開討論了。從這里也基本可以得出一個結論，一個好的組織的領導，一定也是一個很好的架構師。
切分與建模
實際上切分的過程就是建模的過程，每次對大問題的切分都會生成很多小問題，每個小問題就形成了不同的概念。這也是系列第二篇文章嘗試表達的。這些不同的概念大部分時候人們自發(fā)的已經(jīng)建好了，架構師更多的是要去理解這些概念，識別概念背后所代表的的人的利益。比如人類社會按照家庭進行延續(xù)，形成了家族，由于共享一片土地資源，慢慢形成了村莊，村莊聯(lián)合體，不同地域結合，形成了國家。由于利益分配的原因，形成了政權。每次政權的更迭，都是利益重新分配的動力所決定的。
同樣對于一個企業(yè)也是一樣的，一開始一個人干所有的事情。當業(yè)務量逐漸變大，就超過了一個人能夠處理的容量，這些內(nèi)容就會被分解出來，開始招聘人進來，把他們組合在一起，幫助處理企業(yè)的事務。整個企業(yè)的事務，就按照原則2，分出來了很多新的概念：營銷，售前，售中，售后，財務，HR等等。企業(yè)的創(chuàng)始人的工作就變成了如何組合這些不同的概念完成企業(yè)的工作。如果業(yè)務再繼續(xù)增大，這些分出來的部分還要繼續(xù)分拆，仍然要按照原則2才能夠讓各方達到利益最大化。如果某個技術的提升，提高了某個角色的生產(chǎn)力，使得某個角色可以同時在承擔更多的工作，就會導致職責的合并，降低樹的層數(shù)。
切分的輸出和組織架構
架構切分的輸出實際上就是一個系統(tǒng)的模型，對于一個整體問題，有多少的相關方，每個相關方需要承擔哪些權利和義務，不同的相關方是如何結合起來完成系統(tǒng)的整體任務的。有的時候是從上往下切（企業(yè)），有的時候是從下往上合并，有的時候兩者皆有之（人類社會的發(fā)展）。而切分的結果最終都會體現(xiàn)在組織架構上，因為我們切分的實際上就是人的利益。
從這方面也可以看出，任何架構調(diào)整都會涉及到組織架構，千萬不可輕視。同樣，如果對于stakeholder的利益分析不夠透徹，也會導致架構無法落地，因為沒有人愿意去損壞自己的利益。一旦強制去執(zhí)行，人心就開始潰散。這個也不一定是壞事，只要滿足原則2就能夠很好的建立一個新的次序和新的利益關系，保持組織的良性發(fā)展，長久來看是對所有人的利益都有益的，雖然短期內(nèi)有對某些既得利益者會有損害。
總結一下
架構漫談（五）：什么是軟件
前面通過四篇文章，把什么是架構，如何做好架構等必要的概念澄清了一下。這些概念對于在各種不同的領域都應該也是有用的，需要讀者自行思考，并應用到自己所在的領域中。在這篇文章開始，我們用同樣的思考，來看看軟件是怎么回事，以及如何運用架構思維，更好的設計和實現(xiàn)軟件。
馮諾依曼結構，圖靈機，以模擬人為目標
軟件的歷史，實際上可以說是用機器模擬人的歷史。不管大家（包括在這個歷史過程中的參與者）有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。從馮諾依曼結構開始，程序邏輯開始脫離硬件，采用二進制編碼。加上存儲，配合輸入輸出，一個簡化的大腦就出現(xiàn)了。圖靈機則是模擬大腦的計算，用數(shù)學的方式把計算的過程定義了出來，著名的邱奇-圖靈論題：一切直覺上能行可計算的函數(shù)都可用圖靈機計算，反之亦然。軟硬件兩者一結合，一個可編程的大腦出現(xiàn)了，這也是現(xiàn)在為什么我們把計算機叫做電腦。在硬件上編寫出的程序，就是軟件，是用來控制硬件的行為的。
成本為王
在初期，軟件使用二進制編寫的，從硬件到軟件，成本都非常的高。隨著半導體技術的進步，硬件的成本越來越低，性能越來越高，甚至出現(xiàn)了摩爾定律：當價格不變時，集成電路上可容納的元器件數(shù)目，約每隔18-24個月增加一倍，性能提升一倍。軟件方面，為了簡化難度，開始采用匯編，進一步出現(xiàn)了類似于人類的語言的高級語言，比如C/C++/Java等，這使得人類可以用類似于人的語言來和計算機溝通。軟件工程師慢慢越來越多，開發(fā)軟件的成本也越來越低。計算機就好像是一個只需要電，不需要休息的人，可以無休無止的工作。
人們越來越愿意把原來只有人才能做的事情，交給計算機來做。結果就導致軟件越來越豐富，能夠做的事情也越來越多，成本也越來越低。可以這么說，成本是我們?yōu)槭裁床捎密浖闹饕獎恿?#xff0c;可以節(jié)省大量的人員培訓，減少雇員的數(shù)目。隨著互聯(lián)網(wǎng)的發(fā)展，人類社會也開始軟件化了。原來必須實體店來進行售賣的，搬到互聯(lián)網(wǎng)上，開店成本更低，并且能夠接觸到更多的人。想象一下，一個門店每天的人流達到百萬級別是很恐怖的，由實體空間大小來決定。但是在互聯(lián)網(wǎng)上，訪問量千萬級別都不算什么。最終的結果就變成，每個人能夠負擔的工作越來越多，成本越來越低。這也是為什么軟件這么熱的原因。
軟件扮演的角色
隨著軟件的規(guī)模的變大，做好一個軟件也變得越來越難了。早期的程序員寫程序，主要是為了幫助自己研究課題。這些程序員熟練了之后，提高了自己的生產(chǎn)力，并發(fā)現(xiàn)還可以幫助別人寫程序，慢慢軟件就變成了一個獨立的行業(yè)。程序從早期由一個人完成，也逐漸變成了由很多不同角色的人共同合作來完成。以下討論的前提，都是基于幫助別人寫程序，多人合作的基礎上的。結論對于單人為自己寫程序也適用。
在沒有軟件之前，每個人干自己的工作，自行保存自己的工作結果。人們面對面或者通過電話等溝通，如下圖所示。
有了軟件之后，實際上，我們是把我們?nèi)粘Ｉ钪兴龅氖虑?#xff0c;包括我們自己本人都一起虛擬化到了計算機中。而人則演化成了，通過計算機的輸入輸出設備，控制計算機中的自己，來完成日常的工作，以及與其他人的溝通。也就是說，軟件一直以來的動力，始終都是來模擬人和這個社會的。比如模擬大氣運動（天氣預報），模擬人類社會（互聯(lián)網(wǎng)社交），模擬交易，包括現(xiàn)在正在流行的VR，人工智能等等。模擬的對象越來越高級，難度越來越大。
不管如何發(fā)展，模擬人的所有行為都是一個大的趨勢。也就是說，軟件的主要目的，還是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個角度來看，軟件主要依賴的還是人類的生活知識。軟件更多的是扮演一個cost center，這也是為什么會出現(xiàn)很多的軟件代工。
軟件開發(fā)的架構演變
軟件工程師是實現(xiàn)這個模擬過程的關鍵人物，他必須先理解人是怎么在日常生活中完成工作的，才能夠很好的把這些工作在計算機中模擬出來。可是軟件工程師需要學習大量的計算機語言和計算機知識，還需要學習各行各業(yè)的專業(yè)知識。軟件工程師本身的培養(yǎng)就比較難，同時行業(yè)知識也要靠時間的積累，這樣就遠遠超出了軟件工程師的能力了。所以軟件開發(fā)就開始有分工了，行業(yè)知識和業(yè)務的識別，會交給BA，系統(tǒng)的設計會交給架構師，設計的實現(xiàn)交給架構師，實現(xiàn)的檢驗交給測試，還有很多其他角色的配合。為了組織這些角色的工作，還有項目經(jīng)理。這就把原來一個人的連續(xù)工作，拆分成了不同角色的人的連續(xù)配合，演化成了不同的軟件開發(fā)的模式。然后慢慢演變出專門為別人開發(fā)軟件的軟件公司。
軟件架構的出現(xiàn)
如同前面描述的架構的定義，軟件架構的出現(xiàn)也是同樣的。一開始是懵懵懂懂的去寫軟件，后來慢慢的就有意識的去切分，演變成了不同的架構。這個背后的動力也是一樣的，就是提升參與的人的利益，降低成本。導火索也是軟件工程師的任務太重，我們需要把很多工作拆分出來。拆分的原則也是一樣的，如何讓權責一致。同樣，這個拆分也是需要組織架構的調(diào)整，來保證架構的落地。具體如何分拆，如何調(diào)整，我們將在另外一篇中著重討論。
以上通過簡單的描述計算機和軟件的發(fā)展歷史，闡明軟件的本質(zhì)，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產(chǎn)力，提升人類自己的利益。軟件工程師的職責在這個浪潮中，不堪重負，自然而然就分拆為不同的角色，形成了一個獨特的架構體系。這一切的背后，仍然是為了提升人類自己的利益，解決人類自己的問題。
架構漫談（六）：軟件架構到底是要解決什么問題？
前一篇文章簡述了什么是軟件。那么什么是軟件架構呢？按照慣例，我們來看看是什么問題，是誰的問題。
要解決誰的問題？
如前所述，軟件實際上就是把現(xiàn)實生活模擬到計算機中，并且軟件是需要在計算機的硬件中運行起來的。要做到這一點需要解決兩個問題：
一、業(yè)務問題
具體的現(xiàn)實生活狀態(tài)下，沒有軟件的時候，所解決的問題的主體是誰，解決的是什么問題，是如何解決，如何運作的？
二、計算機問題
分別是誰的問題呢？
業(yè)務的owner需要提升業(yè)務的效率，降低業(yè)務的成本，這是動機。這個實際上就是業(yè)務的問題，所以一般軟件開發(fā)的出發(fā)點就在這里。
是軟件工程師的問題，要解決業(yè)務owner把業(yè)務虛擬化的問題，并且要解決軟件開發(fā)和運營的生命周期的問題。
分別有什么問題？
業(yè)務問題的本質(zhì)，是業(yè)務所服務的對象的利益問題，明白了這個，就很容易搞清業(yè)務的概念和組織方式。再次強調(diào)一下，有了軟件，可以降低業(yè)務的成本，沒有軟件的情況下，業(yè)務是一樣跑的。如果只是為了跟風要用軟件，說不定反而提高了成本，這個是采用軟件之前首先要先搞清楚的。我們經(jīng)常說軟件和技術是業(yè)務的enabler，實際就是把原來成本很高的降到到了很低的程度而已，并不是有了什么新的業(yè)務。另外，軟件也不是降低業(yè)務成本的唯一方式。
為了能夠讓軟件很好的跑起來，軟件工程師必須理解業(yè)務所服務的對象，他們的利益所在，即業(yè)務問題。業(yè)務面對這些問題是如何分拆解決的？ 涉及到了哪些概念？ 這些概念分別解決了哪些哪些問題？ 我們不能自己按照自己的理解，用自己的一套概念體系來表述。如果這么做的話，會導致兩個問題：
1）業(yè)務無法和我們交流，因為他們無法明白我們所自己創(chuàng)建的概念，所以他們無法確認我們的理解是否正確。
2）我們所表述的東西，并沒有在實際生活中實踐過，我們也不知道這些概念是否能夠解決業(yè)務的問題。
軟件工程師還必須要考慮，用什么樣的硬件把軟件跑起來，怎樣跑得好，跑得快，并且可以隨著業(yè)務的流量逐漸的長大？
分析問題
對于2，在有限的時間下，軟件工程師毫無疑問無法一個人去完成這么多事情，那么我們需要把所做的事情列出來，進行分析。
一、虛擬化業(yè)務需要完成這些事情：
學習業(yè)務知識，認識業(yè)務所涉及的stakeholders的核心利益述求，以及業(yè)務是如何分拆滿足這些利益訴求，并通過怎樣的組織架構完成整個組織的核心利益的，以及業(yè)務運作的流程，涉及到哪些概念，有哪些權利和責任等。
通過對業(yè)務知識的學習，針對這些概念所對應的權利和責任以及組織架構，對業(yè)務進行建模，并把建模的結果用編程語言實現(xiàn)。這是業(yè)務的模型，通常是現(xiàn)實生活中利益斗爭的結果，是非常穩(wěn)定的。
學習業(yè)務所參與的stakeholder是如何和業(yè)務打交道，并完成每個人的權利和義務的，并通過編程語言，結合業(yè)務模型實現(xiàn)這些打交道的溝通通道。這部分是變化最頻繁的，屬于組合關系。明白了這一點，對后續(xù)的實現(xiàn)非常有幫助。
如何把業(yè)務運行的結果持久化，并通過合適的手段把持久化后的數(shù)據(jù)，在合適的時間合適的地點加載出來。這部分和基礎設施有關，變化可能也會比較頻繁。
二、代碼如何運營，需要完成這些事情：
三、如果分成不同的角色來完成這些事情，就需要一個組織架構來組織代碼的編寫和運營，需要做哪些事情：
會生成哪些架構
如果業(yè)務足夠簡單，用戶流量夠小，時間要求也不急迫，那么一個人，一臺機器就夠了，這個時候一般不會去討論架構的問題。當訪問的流量越來越大，機器就會越來越多，代碼的部署單元就會拆分的越來越多。
同樣就會需要越來越多的人來完成拆分出來的越來越多的部署單元，甚至同一個部署單元也需要分拆為多人合作完成。但是我們需要注意到一點，整個的概念體系，或者說業(yè)務的建模不會有任何的變化，還是完成同樣的這些事情。唯一的區(qū)別就是量越來越大，超過了單個人和單個機器的容量，不斷地增長。這樣就會導致以下的架構：
當流量越來越大，我們就會發(fā)現(xiàn)，軟件所部屬的機器就會開始按照樹狀的結構開始分拆，就會形成硬件的部屬架構。這就是為什么會形成部署的分層。
為了把業(yè)務在軟件中實現(xiàn)并落地，需要前端人員、業(yè)務代碼人員、存儲層等不同技巧的人同時工作，需要切分成代碼的架構。這就是為什么會形成代碼的分層，形成代碼的架構。當然，當這些角色由一個人來完成的時候，不一定會有代碼架構，往往會比較亂。
當參與的人員越來越多，就會形成開發(fā)體系的組織架構。因為代碼開發(fā)的過程是一個連續(xù)的過程，會用流程來把不同的角色串聯(lián)起來，這就是軟件工程。
為了完成業(yè)務的工作，需要識別出來業(yè)務架構和支撐業(yè)務的組織架構，以及業(yè)務運作的流程。這是被虛擬化的業(yè)務架構和組織架構，也需要體現(xiàn)在代碼中，保持和現(xiàn)實生活中一致。
什么是軟件架構
這就是軟件比較復雜的地方，涉及到軟件本身的業(yè)務體系，和所虛擬的業(yè)務體系。根據(jù)以上的分析，所生成的架構，究竟那些算是軟件架構呢？
軟件因為流量增大而分拆成不同的運行單元，在不同的機器上部署所形成的架構，屬于軟件架構。
每個運行單元為了讓不同角色的人，比如前端，業(yè)務，數(shù)據(jù)存儲等能夠并行工作，所分成的代碼架構，也屬于軟件架構。
所以當我們說軟件架構的時候，我們一定要講清楚，究竟說的是部署的架構，還是代碼的架構。軟件架構的落地，需要軟件的組織架構和流程來保障，離開了這個，軟件架構是一句空話。
另外很多人講，架構是進化出來的。架構實際上是在量不斷的增大，超過了單臺服務器的容量，逐漸的分拆，同時導致超過單個人員的能力，工作人員不斷的增多，工作內(nèi)容不斷的分拆形成的。這本身就是架構的意義所在。不管怎么分拆，所達到的目標沒有任何變化，就是完成業(yè)務在計算機中的虛擬化。
?
架構漫談（七）：不要空設架構師這個職位，給他實權
什么是架構師
在之前的幾篇文章中，經(jīng)常會提到架構師這個詞。我們已經(jīng)定義了什么叫架構，那怎么定義架構師呢，是不是做架構的就叫架構師了？ 沒有這么簡單，本篇嘗試討論一下這個問題。
架構師的前提條件
如果一個人在工作中，只是致力于完成自己的工作，以做好自己的工作為主要目標，那么最多只能成為一個工匠，無法成為一個架構師。因為這個過程解決的還是自己的問題，并沒有時間的壓力，可以隨意什么時候做完都可以。
當我們所做的工作是處于社會的分工的一環(huán)，需要幫助別人解決問題，并且按時解決別人的問題成為我們自己的問題的時候，我們就有了時間壓力，潛意識里會自然而然的有一種對時間的恐懼。這個恐懼在潛意識里面會想方設法推動我們采用各種手段，以便及時的完成工作，換取報酬。甚至會加班加點，不擇手段。
如果我們還生活在這個恐懼下面，是不可能成為架構師的。要成為架構師，必須要超越這個恐懼才能夠看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因為僅僅是完成了自己的工作，也并不一定就解決了別人的問題。如果別人的問題沒有解決——即使我們認為自己的工作完成了——我們的工作實際也沒完成，因為我們工作是否完成，是別人說了算的，不是我們自己。
為什么會有這個對時間的恐懼和壓力呢？這是因為我們把完成自己的工作當成了我們的最大利益。如果別人的問題沒有真正的解決，必然會覺得付出的報酬不值得，我們的利益實際上是受損失了。這和我們所以為的恰恰相反，因為我們所能得到的工作只會越來越少，別人會越來越不愿意依賴于我們。
另一方面也說明，我們對自己所從事的工作，還沒有足夠的自信，我們解決自己的問題還有困難，才會這么在意，并恐懼。如果我們把完成別人工作當成自己的最大利益，這個對時間的恐懼自然就會消失，這個時候就自然而然的開竅了，就知道怎么去發(fā)現(xiàn)問題了。只有做到這一點，才能在自己所服務的領域建立起自信，成為一個合格的架構師。
其實剛開始一般是硬著頭皮去克服對時間的恐懼和壓力的，一點自信都沒有。但只要做成功了一次（只要真的舍得這么去做了，想不成功也很難！），自信就開始慢慢建立起來了，這個時候就是我們開始慢慢變成架構師的時候。大家就當著上當一回，試試看。
如何發(fā)現(xiàn)“是誰的問題”
當我們真正專注于別人的問題的時候，我們自己的理想，抱負，對技術的追求都不算什么了。這些理想，抱負，對技術的最求，不就是要達到自己的利益嗎？ 只有幫助別人解決了問題，這些理想，抱負，對技術的追求才可能實現(xiàn)，否則這些理想，抱負，對技術的追求有什么意義，能得到什么利益？
這個時候就會真正的開始思考，別人究竟有什么問題。其實也很簡單，和我們自己面臨的問題一樣，別人的問題也都是如何獲取更好更多的利益。我們自己想明白了這一點，自然也就能想明白別人的問題。這個時候就能夠問出正確的問題：如果問題不解決，究竟誰會有利益的損失？ 如果問題解決了，究竟誰會有收益，誰的收益最大？ 回答了這兩個問題就找到了問題的主體。只回答一個是沒有用的，因為很多時候這個世界的事情，權責是不對等的。明白了這兩個問題，我們只要讓事情權責對等起來，讓每個人為自己的權利產(chǎn)生的結果負有義務，大部分時候我們自己根本就不需要做什么，問題就都解決了。這就是最高明的架構師。
架構師的權利和義務
架構師是要去平衡別人的利益，甚至會調(diào)整別人的利益的。一旦架構師是全心全意的為別人的利益服務，自然而然的架構師就擁有了強有力的影響力，肯定會是一個leader。但是只是民意上的leader是沒有用的，不能完全發(fā)揮架構師的能量。
架構師必須是一個組織的領導人，有權利調(diào)動這個組織的架構，才能夠更好的發(fā)揮架構師的作用，更好的把利益的調(diào)整落到實處。所以很多公司設了很多架構師的職位，但是并不具備調(diào)動組織架構的權利，那么這個架構師的職位一定是形同虛設。架構師只能夠通過建立某些流程來行使架構師的權利，比如強制架構review，反而會造成很多內(nèi)部不必要的沖突，最終都會導致這些流程流于形式，得不償失。相信很多人都已經(jīng)經(jīng)歷過這些，但似乎很少有人回去探討這是為什么。
反過來，具備架構師能力的組織領導人，一定是一個很好的領導，這個組織一定是很健康向上的，因為每個人的權利和義務就是比較均等的。并且這類領導對于組織成員權利和義務的對等狀況會非常的敏感，會及時的調(diào)整組織架構，在問題發(fā)生之前就解決了。這樣這個組織就會具備更好的抗壓能力，能夠更好的為這個組織的客戶服務，這個組織的成員內(nèi)心一定都是比較平衡的，每個人的能力都能夠得到比較好的發(fā)展。當然讀者可能又會說，這不是管理學的東西嗎？ 是的，但也是架構的問題。所有架構的核心就是組織架構。或者也可以這樣說，一個合格的組織領導人，一定必須是一個合格的架構師。
架構師的義務似乎不用說了，大家提的要求可能比我提的都高 —— 當然是發(fā)現(xiàn)問題并且解決問題。架構師必須能夠超越對時間的恐懼 —— 也就是說必須具備了一定程度的自信，哪怕是裝的，去真正的發(fā)現(xiàn)問題的主體，識別真正的問題，并把這個行為變成為自己面對問題的第一反應。架構師還必須要明白，所給出的解決方案 —— 架構的分拆、合并方案，只有讓問題的主體的權責對等，才能夠真正的解決別人的問題。一般明白了問題的主體，以及主體的利益所在，做到這一點也沒有問題。
架構師和技術
很多人會問，特別是做軟件行業(yè)的，架構師是不是需要學習技術，甚至是學習語言？ 如果一個架構師還有這個困擾——就如問這個問題的人，說明目前還不具備做架構師的能力，或者說還不具備對自己領域——哪怕是技術領域——的自信，更別談業(yè)務領域了。
因為技術和語言，都是用來識別和解決所服務的主體的權責，保護并提升所服務的主體的權利的。特別對于軟件領域來說，必須明白軟件本身是怎么回事，解決什么問題，還要解決軟件所服務的對象的領域本身是怎么回事，解決什么問題，這就要求更高了。語言和技術應該是隨手拈來才對，對于架構師這些都是工具。學習技術和語言，如果明白了這些技術和語言要解決的是誰的問題，什么問題，學起來是非常快，非常容易的。
同樣，采用哪個技術或者語言，只要某個技術或語言所解決的問題的主體，以及所解決的問題，和自己所面對的問題的主體和這個主體要解決的問題，這兩者是匹配的，那么這個方案的成本是最低的，所采用的技術或者語言就是靠譜的。沒有趁手的工具或語言的情況下，自己設計一個也不難，因為很清楚自己要什么。要不要自己做，無非是一個成本問題，也就是利益問題。并且從這個思路下去，選擇的工具和語言肯定都是最簡單的，成本是最低的。因為架構畢竟解決的還是人的利益問題，成本越低越好，這個成本當然是長期總體成本，不是眼前的短期成本。
架構漫談（八）：從架構的角度看如何寫好代碼
在第六篇文章中，我們得出一個結論，軟件架構實際上包括了：代碼架構，以及承載代碼運行的硬件部署架構。實際上，硬件部署架構最終還是由代碼的架構來決定。因為代碼架構不合理，是無法把一個運行單元分拆出多個來的，那么硬件架構能分拆的就非常的有限，整個系統(tǒng)最終很難長的更大。
所以我們經(jīng)常會聽說，重寫代碼，推翻原有架構，重新設計等等說法，來說明架構的進化。這實際上就是當初為了完成任務，沒有充分思考所帶來的后果。這也并不是架構進化的事情，而是個人對問題領域的逐漸深入理解的過程。所以有必要再討論一下，代碼的架構應該是怎樣的。
本文會在之前幾篇文章的基礎上，進一步探討如何把架構的思考進行落地，細化到我們代碼的實踐當中，盡量不要讓代碼成為系統(tǒng)長大的瓶頸，降低架構分拆的成本。
在前面我們提到，軟件實際上是對現(xiàn)實生活的模擬，虛擬化。這是一個非常重要的前提，直接決定了我們的代碼應該分為幾部分。結合每個部署單元所承擔的責任，可以明確的拆分為兩個不同的責任：
表達業(yè)務邏輯的代碼。很多人把這部分叫做Domain Logic，或者叫Domain Model。這部分實際是來源于生活的，必須保持和現(xiàn)實生活中的切分一致，并非人為的抽象而成。
對用戶提供訪問并保存業(yè)務邏輯運行結果的代碼。計算機的狀態(tài)保存有一個缺陷，本機保留業(yè)務運行結果有很大的問題，一般都在外存儲設備上保存，也便于擴展。
所以單個部署單元的代碼可以分為兩個部分，如下圖所示：
從這個圖中可以看出，軟件代碼的相關利益人為運行時的訪問人員和存儲設備。而service的代碼是最復雜的，需要服務于三方，代碼人員的負擔是最重的。為了把這三方的變化對service的影響降到最低，對于service還必須進一步的分拆為三個部分，讓每一個部分都能夠獨立的變化，這樣這三方的變化就不會產(chǎn)生連鎖響應，降低成本。如下圖所示：
這樣，就劃分成了幾個責任：
Service就專注于user的需求，并組合Glue Code提供的服務完成需求。
Glue Code專注于組合business的調(diào)用，管理Business里面對象的生命周期，并且通過Repository保存或加載Business的狀態(tài)
Business專注于實現(xiàn)業(yè)務的核心模型。
Repository專注于數(shù)據(jù)的保存，并和存儲設備一一對應。
大家注意看，還是樹形架構。并且左側的主要需要計算機的相關理論知識，并且要直接面對用戶的需求。右側的更多的需要面對業(yè)務的核心。只要這幾塊的開發(fā)人員互相商量好了接口定義，這幾個部分的開發(fā)就可以并行的進行，極大的提升開發(fā)的效率，縮短開發(fā)的時間。要做好這幾部分，還需要注意，邏輯只允許存在于Business中，Service、Glue Code、Repository都不允許存在業(yè)務邏輯。為什么呢？首先我們來看看什么叫業(yè)務邏輯。
什么叫業(yè)務邏輯？
首先這個定義的前提是指軟件代碼中的邏輯，不是現(xiàn)實生活中的邏輯。在軟件代碼中，不需縮進和計算的順序調(diào)用，包括縮進的代碼目的是catch exception的，都不算邏輯，除此以外都是邏輯。以下用嚴格的順序調(diào)用來指代這種代碼。因為順序調(diào)用是計算機的特性，由編譯器來決定的，當然最本質(zhì)的是因為我們計算的基礎都是圖靈機。在現(xiàn)實生活中，順序調(diào)用也是邏輯，大家不要和我們這里說的業(yè)務邏輯相混淆。
為什么說除了Business代碼中有邏輯以外，其他地方不能有邏輯呢？ 我們每個部分分別分析：
如果service里面不是嚴格的順序調(diào)用，有很多分支，那么說明這個service做了兩件或者兩件以上的事情。必須把這個service分拆，確保每個service只做一件事情。因為如果不這么分拆的話，一旦這個service中的某各部分發(fā)生變動，其他的部分的執(zhí)行必定會受影響。而確定到底有哪些影響的溝通成本非常高，其他相關利益方?jīng)]有動力去配合，我們往往不會投入精力仔細評估。最后上線會出很多不可預料的問題，最終會導致?lián)p失用戶的利益，并且肯定會導致返工，損壞自己的利益。如果是有計算的邏輯的話，比如受益計算，訂單金額計算等，那么這部分應該是Business代碼需要完成的，不能交給service代碼來實現(xiàn)。
Glue Code里面如果不是嚴格的順序調(diào)用，同理會和service一樣遇到同樣的問題。
Repository里面如果不是嚴格的順序調(diào)用，包括存儲訪問的代碼里面（比如SQL），會導致邏輯進入到存儲設備中。存儲設備的主要目的是拿來存儲的，一旦變成了邏輯計算的主體，就會導致存儲設備無法通過增加機器的方式橫向擴展長大。這個時候就沒有架構了，只能換性能更好的機器，這個叫scale up。只有scale out才能算架構。
以上都會導致架構無法快速的橫向擴展和分拆，并且增加了修改的成本，這些是不符合開發(fā)人員以及業(yè)務的利益的。
這么做的好處有哪些呢？
Service、Glue Code、Repository里面的代碼是嚴格的順序調(diào)用，那么這些代碼只要做連通性測試即可，不需要單元測試。因為這些代碼都需要和很多上下文打交道，很難做單元測試。這樣才算是真正的組合。
Business不訪問任何上下文，不訪問任何具體的設備，所以這部分代碼是非常容易寫單元測試的，并且單元測試必須100%覆蓋。因為其他地方?jīng)]有業(yè)務邏輯，所以一旦有問題，就可以斷定是Model的問題，單元測試肯定可以發(fā)現(xiàn)。如果單元測試沒有發(fā)現(xiàn)問題，那么單元測試一定有問題。線上問題的模擬也就變得非常的簡單，單元測試也能夠得到進一步的補充。
Repository很容易按照存儲設備本身的最小訪問粒度來完成工作，比如DB，完全可以做到單表訪問。因為這個時候存儲設備只關心存取數(shù)據(jù)，完全和業(yè)務沒有關系。做表的分拆也是非常容易的事情，存儲設備通過增加機器就可以橫向擴展長大。很多人會擔心說，沒有了join，訪問DB的次數(shù)是不是更多了，會導致性能下降？ 按照現(xiàn)在網(wǎng)絡的條件，網(wǎng)絡訪問和Disk IO訪問的差距已經(jīng)不大了，合理的設計下，多訪問幾次DB并不會導致這個問題。另外如果多臺DB的話，還能通過并行加速訪問。
由于Service、Glue Code、Repository代碼簡單了，才可以讓我們的開發(fā)人員投入更多的時間研究業(yè)務，畢竟這部分才是軟件所真正服務的對象。
我們再來看一個實際的例子，如下圖所示：
Manager類實際就是Glue Code。有幾個注意點需要說明一下：
不能把Business Model當做數(shù)據(jù)對象來處理，Model關心的實際上是業(yè)務行為，數(shù)據(jù)只是是這些行為的結果。所以Glue Code需要把Model轉(zhuǎn)換為Entity，Entity和存儲設備里面的存儲粒度一一對應。比如在DB中，每個Entity對應一張表，并且跟著表的變化而變化，這樣就保證存儲的變更不會影響Model。同樣Service和用戶之間的數(shù)據(jù)交互，也是不會和Model之間相關的，確保用戶的需求變化，不會影響到Model。因為用戶的需求變化是最頻繁的，沒有邏輯，可以讓我快速的滿足業(yè)務的需求。
在Service這里，最好不要考慮代碼重用。因為當多個不同的角色訪問同一個接口，一旦某個角色的需求發(fā)生了變化，就會要求開發(fā)人員去修改。而這個修改往往會影響到其他的角色，需要這些角色一起配合來確定是否受影響，但是這些角色因為沒有需求，往往不會配合。這樣就給開發(fā)人員造成了很多不必要的溝通，成本是非常高的。最終都會導致線上Bug，影響最終的用戶。所以盡量給不同的角色不同的Service，避免重用，降低溝通成本。很多人會說這樣Service不就太多了嗎？ 這樣Service注冊，查找等管理需求就出現(xiàn)了，Service治理中心就是來解決這個問題的。因為Service里面沒有邏輯，所以開發(fā)和管理非常的簡單，可以快速應對業(yè)務的變化。我們只有更快地變，更容易的變，才能更好地應對變。
Business Model是必須要重用的，一旦發(fā)現(xiàn)重用出現(xiàn)問題，那么說明Business Model的識別出現(xiàn)了問題，這是一個我們要重新思考Model的信號。Business Model必須是一個完美的樹狀，如果不是，也說明Model的識別出了問題。
在實際操作中，Service、Glue Code、Repository不能有邏輯，實際上和很多人的觀念是沖突的，認為這個根本做不到。做到這一點需要很多的學習成本，但是一定可以做得到。當發(fā)現(xiàn)做不到的時候，可以斷定是業(yè)務的分析出了問題。比如不該合并的合并了，不該計算的計算了。這個問題一定有辦法解決的，做不到都是理由，無非是想早點把自己的工作結束罷了。雖然剛開始會比較困難，一旦把這個觀念變成自覺，開發(fā)的質(zhì)量和效率馬上就能高好幾個級別。
我的游泳教練曾和我說過這些話，我至今記憶猶新：“業(yè)余選手，越想從水里浮起來，就越想把頭抬起來，身體反而沉下去。只有克服恐懼，把頭往水里壓下去，身體才能夠從水里浮起來。真正專業(yè)的習慣往往是和我們?nèi)粘５男袨橄喾吹?/strong>”。
我們真正想快速的完成代碼工作，就要克服自己對時間的恐懼，真正的去研究業(yè)務的問題，相關stakeholder的利益，把這個變成我們的習慣。寫代碼的時候讓該出現(xiàn)邏輯的地方出現(xiàn)邏輯，讓不該出現(xiàn)的地方不能出現(xiàn)。一旦不該出現(xiàn)的地方出現(xiàn)了邏輯，那么要馬上意識到，這個地方是一個坑，這個問題一定和業(yè)務的分析不透徹有關系。
很多人可能會把這個做法和Martin Fowler曾經(jīng)提出過充血模型和貧血模型來比較，和Domain Driven Design來比較，其實沒有必要。這個分拆完全是從軟件所解決的問題，根據(jù)軟件架構推導出來的，很多地方和兩位前輩的觀點是一致的，但是并不完全等同。
以上只是針對單一的Service部署單元的分析，擴展開去，對于其他的部署單元也是類似的。每個單元的下一級都可以認為是Repository，每個單元的上一級都可以認為是User。這些實踐在我自己的項目中都有用到，非常的有效，迭代的速度非常的快。很多人擔心Business Model建不好，其實沒關系，剛開始可以粗糙一點，后續(xù)可以慢慢的完善。這個架構已經(jīng)隔離好了每個部分的變化對其他部分的影響，變化成本都在可控的范圍之內(nèi)。
架構漫談（九）：理清技術、業(yè)務和架構的關系
某天和朋友吃飯正好聊到這個話題。作為架構師或者做技術的人，在開發(fā)軟件時，我們基本上就是在扮演上帝的角色：我們不但要創(chuàng)建出一個個的程序，還要讓這些程序能夠脫離我們在硬件上獨立運行，以便為這個程序所服務的群體提供服務。當這個程序出現(xiàn)問題甚至bug的時候，我們還得扮演牧師的角色去修復這些問題。這不正是一個程序的社會嗎？ 和人類社會的演變何其相似！那么我們自然也能夠拿人類演變的歷史來指導軟件開發(fā)工作，以避免再經(jīng)歷一次像人類演變發(fā)展那么痛苦的過程了。由此我們也可以看出，架構師和程序員們都在扮演著多么重要的角色，如果還在解決自己的問題，怎么扮演好上帝這個角色？
在軟件設計開發(fā)的過程中經(jīng)常會看到，很多所謂的架構討論實際上只是在討論某種技術。在很多人的概念里面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術都是為了解決某種問題而存在的，學會了技術，并不代表自己能夠解決問題，這一點非常的重要。學會的技術的多少，所帶來的差別只是自己解決問題的手段多了罷了。但是手段多了就一定是好事嗎？ 很多時候，學習的技術越多，越不知道采用哪種技術好，所謂“亂花漸欲迷人眼"。
還有另一種很普遍的觀點：技術人普遍看不起業(yè)務，認為技術更高端，而業(yè)務太低端，并且業(yè)務往往喜歡給技術挖坑。業(yè)務則覺得技術眼光高，但是實際解決不了問題，總是理解有偏差，但是又無可奈何，因為自己不會。
本篇文章嘗試從這里入手，分析一下這三個概念到底有什么關系，我們應該怎么處理業(yè)務、技術還有架構的關系。
什么是技術
當我們一無所有，或者什么都不會的時候，這個時候?qū)嶋H上是沒有技術的。就好比人類在最早期，什么都得用自己的雙手來干活。一旦我們在日常生活中無意間發(fā)現(xiàn)某些規(guī)律的時候，我們就可以通過創(chuàng)造條件，讓這個規(guī)律重復的發(fā)生。通過人為創(chuàng)造條件，讓指定的規(guī)律按照人類的意愿發(fā)生，這就是技術。
比如取火，最早人類只能靠打雷等自然現(xiàn)象產(chǎn)生火。取火其實就是一個業(yè)務目標，要解決的是人類自己的問題，這就是業(yè)務，實際就是人類的利益。這個時候人類沒有生火的技術，只能靠不斷的加木材，保持火不熄滅。后來人們發(fā)現(xiàn)了鉆木取火：只要用一個干的木棍，在另一個干木表面快速的轉(zhuǎn)動，就可以生火。這個辦法讓人類可以自行創(chuàng)造火源，就產(chǎn)生了鉆木取火的技術。
但是雙手快速轉(zhuǎn)動木棍鉆木取火，并不是所有人都能夠做得到的，需要很多力量和速度，對人的要求太高。為了解決快速轉(zhuǎn)動的問題，就有人采用弓弦來提升木棍轉(zhuǎn)動的速度。
也就是說：
業(yè)務目標是為了取火，鉆木取火這個技術的出現(xiàn)解決了這個問題。
鉆木取火的效率不高，影響了業(yè)務（取火）的效率，就有了進一步改進的動機，改進轉(zhuǎn)動木棍的方式，產(chǎn)生了弓弦轉(zhuǎn)動木棍的技術。
技術與架構，以及與業(yè)務之間的關系
技術總是在人類解決對業(yè)務的要求不斷提高的情況下產(chǎn)生，目的也是為了獲取更大更好的利益。所以：
技術是為了解決業(yè)務的問題而產(chǎn)生的，沒有了業(yè)務，技術就沒有了存在的前提。
有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求——也就是業(yè)務。有人會問，不用鉆木取火了，但是弓弦加速轉(zhuǎn)動木棍還可以用啊？ 沒錯，因為弓弦轉(zhuǎn)動木棍這個技術，不是來生火的，是用來加速木棍轉(zhuǎn)動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業(yè)務問題。
所以技術與技術之間，有兩種關系：
在解決同一個業(yè)務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。
一般剛開始解決根本問題的技術（鉆木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業(yè)務的enabler）。然后就會有提高效率的需求出現(xiàn)，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發(fā)明人自己）加以改進，這部分就會形成新的技術。
當關系2發(fā)生的時候，這個地方必定會形成一個切分，新技術會通過某種方式和原有的技術連接在一起形成一個整體，讓這個新的技術可以和原有技術共同工作，使得原有的技術可以用更高的效率解決問題。因為要解決的主要問題（生火）并沒有發(fā)生改變，分拆所形成的是一個樹狀的結構。
按照前面的架構定義，這個時候其實已經(jīng)產(chǎn)生了架構。也就是說，一般是先有技術，才會有架構。這些其他技術（弓弦拉動木棍），是從直接解決問題的初始主要技術中分拆出來形成的，并通過樹狀結構和主要技術（鉆木取火）組合在一起。在解決主要問題（生火）之后，再開始逐漸的分拆為更為細粒度的技術（弓弦轉(zhuǎn)木棍）。
而這個細粒度的技術（弓弦轉(zhuǎn)動木棍）往往不會和業(yè)務的主要目標（生火）發(fā)生直接的關系。不同的技術，通過樹狀結構，組合在一起，形成了一個完整的架構解決方案，共同完成業(yè)務的目標。這就是技術，業(yè)務和架構之間的關系。很多人把這個過程稱為架構的進化，我更愿意把這個過程稱為技術的進步所導致的新的架構分拆，因為這個過程內(nèi)在的動力，更多的是來自技術對業(yè)務問題的解決。
技術人員和業(yè)務人員的關系
為什么技術人員總是和業(yè)務人員發(fā)生沖突呢？ 這是因為技術人員很多時候關心的技術，和業(yè)務的主要目標往往不是直接對應的，業(yè)務也是負責某一部分的業(yè)務，也不是和業(yè)務的主要目標直接對應的，都是樹的分支節(jié)點（上文已經(jīng)解釋了為何會發(fā)生這種情況）。只有直接解決業(yè)務問題的那個技術（或業(yè)務）—— 樹的根節(jié)點 —— 會和業(yè)務直接相關。所以一旦產(chǎn)生沖突，一般必須兩個根節(jié)點（一般都是領導）碰面才能解決問題，就是這個原因——他們都知道業(yè)務主要目標。這也是為什么下層無法理解上層，而上層都喜歡下軍令狀，要求下層執(zhí)行。人只有盡量去理解上層的問題才能做下層的分拆。
在軟件行業(yè)，這個根節(jié)點技術就是軟件。這也是為什么架構師要認識什么叫軟件，軟件解決誰的問題，什么問題，軟件本身又是怎么分拆的，才能夠更好的組合不同的技術，完成業(yè)務的目標。而軟件里面和業(yè)務直接相關的，只有Business Domain這一部分。
用人來打比方，Business Domain相當于人的大腦，而Service，Repository，Glue Code等部分所采用的技術，全部都是計算機自己領域的技術，都是為了能夠讓程序跑起來，相當于人的四肢。我們大部分開發(fā)人員的工作主要專注于四肢部分。我們真正應該投入的是大腦部分。因為大腦能夠決定四肢長什么樣，而不是反過來。很多架構師、技術人員主要專注于計算機相關的技術，忽略了業(yè)務本身，甚至看不起業(yè)務，這也是為什么技術總是和業(yè)務沖突的原因。
架構師應該承擔起解決業(yè)務問題的這個角色來，專注于Business Domain和軟件本身的架構，讓技術人員致力于為業(yè)務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業(yè)務的目標，才會讓軟件更好地服務于大家。最終一定會得到一個很好的軟件架構，令軟件開發(fā)團隊和業(yè)務部門都能夠很好地開展工作并降低成本。
重新發(fā)明輪子
當現(xiàn)有已經(jīng)存在很多技術，而這些技術卻和我們所要解決的問題并不是那么直接對應的時候，我們就需要有意識的組織和識別不同的技術，來實現(xiàn)業(yè)務的目標。這個時候組織的方式有很多種，其中成本最低的方法就是按照要達成的目的和當前的問題，從上到下進行架構分拆。分拆出來的更細粒度的問題，分解到不同的人來進行解決，就形成了業(yè)務架構和組織架構。解決這些問題就需要組合很多不同的技術，那么應該采用哪些技術？還是自己重頭實現(xiàn)一個？ 自己實現(xiàn)一個——這就是很多人所謂的重新發(fā)明輪子。以下試著分析一下：
當技術所解決的問題和分拆出來要解決的問題，完全匹配的時候，這是最完美的。比如需要提供web要訪問的service，很多MVC的framework就可以很好的滿足這一點。而這個時候如果非要自己實現(xiàn)一個，很有可能就是重新發(fā)明輪子。
當技術所提供的能力遠遠超過需要解決的問題時，往往掌握技術和維護技術會成為瓶頸。因為越復雜的技術，成本越高。如果自己實現(xiàn)一個僅僅是解決當前問題的方案，可能成本反而更低。這也是為什么很多大型的互聯(lián)網(wǎng)公司不斷地開源出來自己的技術的原因。而這些技術對于我們來說是否適用？他們原本是用來解決誰的問題的？什么問題？如果不清楚這些，就冒然采用，可能會導致更高的成本。
當技術所提供的能力和我們所要解決的問題部分匹配時，還是要看成本。比如當我們需要一個錘子的時候，手邊正好沒有，但是卻有一只高跟鞋，勉強也可以替代錘子。但是長期來看，這么用不劃算，因為高跟鞋的價格比錘子高很多，耐用性差很多，維護成本也高很多。
所以，準確識別采用什么技術的能力，也是架構師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。
?
轉(zhuǎn)載于:https://www.cnblogs.com/gym333/p/8508012.html
總結
以上是生活随笔為你收集整理的架构漫谈（一）：什么是架构？ -王概凯 - 转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用linux c开源库libwebso
- 下一篇： 地图API哪个好用