架構(gòu)設(shè)計系列文章，請參見連接。

0. 背景

想成為架構(gòu)師或者已經(jīng)是架構(gòu)師的同學(xué)有沒有問過自己一個問題：為什么你是架構(gòu)師咽安？其實就是問問自己為什么想成為架構(gòu)師，是不是真的是一個架構(gòu)師竖幔？架構(gòu)師只是一個稱呼板乙，并不是你擁有了這個稱呼就是架構(gòu)師了。最主要的問題還是架構(gòu)師和其他崗位同事的思維模式是有質(zhì)的區(qū)別的拳氢。

很多公司為了職級的完整性而定義的架構(gòu)師募逞，技術(shù)專家到底是不是同一個概念？在某些時候授予了一些人馋评，做了一些事可以認(rèn)為他們就是架構(gòu)師了嗎放接？我們這里討論和追逐的真理是你自己本身認(rèn)為你是個架構(gòu)師，而不是外部的授予留特。

本文主要從幾個方面為什么你是架構(gòu)師：

1. 為什么你是架構(gòu)師纠脾？
   主要以排除法說明什么崗位的同事并不是架構(gòu)師。
2. 架構(gòu)師的目標(biāo)與定位
   架構(gòu)師以什么作為目標(biāo)和責(zé)任來幫助團隊完成系統(tǒng)研發(fā)工作蜕青。
3. 架構(gòu)師的思維方式（重點）
   架構(gòu)師最主要的與其他人不同的點苟蹈。
4. 架構(gòu)師的執(zhí)行力（架構(gòu)師落地的過程）
   架構(gòu)師要有自己的執(zhí)行能力，去具體的落地架構(gòu)設(shè)計以及解決落地過程中的問題右核。
5. 架構(gòu)師的溝通能力（架構(gòu)師核心的說服力）
   與團隊慧脱，上級之間溝通推行架構(gòu)設(shè)計中的目標(biāo)。

1. 為什么你是架構(gòu)師贺喝？

架構(gòu)師不是框架師菱鸥、不是算法工程師、不是高級程序員躏鱼、不是項目經(jīng)理氮采。架構(gòu)師與這些崗位的同事有著很多共同點，導(dǎo)致很多在軟件行業(yè)從業(yè)多年的人都分不清他們之間的區(qū)別染苛。本文從不同點出發(fā)說明架構(gòu)師的特點鹊漠。

1.1 架構(gòu)師并非框架師

框架和架構(gòu)的區(qū)別大家都是知道的，可以說框架也是有架構(gòu)的茶行。并且框架的問題域中有一個問題是怎么解決業(yè)務(wù)軟件開發(fā)過程中的架構(gòu)問題贸呢。所以說，框架影響著架構(gòu)但框架并不是架構(gòu)拢军。因為架構(gòu)中除了框架外還有中間件、組件需要由架構(gòu)師來處理怔鳖，描述框架茉唉、中間件、組件等之間的關(guān)系是架構(gòu)設(shè)計過程中技術(shù)選型內(nèi)的一部分。

對框架的架構(gòu)進行設(shè)計與演進也是架構(gòu)師的工作度陆，就現(xiàn)在來說軟件開發(fā)基礎(chǔ)設(shè)施的開發(fā)團隊很少艾凯，并且軟件框架的架構(gòu)設(shè)計技術(shù)了解的人也很少。所以懂傀，可以認(rèn)為框架只不過是一種特殊的軟件趾诗，它解決的是軟件開發(fā)與運行階段的問題。

可以說對于架構(gòu)師來說蹬蚁，框架只不過是一種特殊的軟件恃泪，就看要實現(xiàn)的軟件是框架、中間件犀斋、組件還是業(yè)務(wù)軟件根據(jù)軟件所處領(lǐng)域的不同進行針對這個領(lǐng)域中的問題進行分析和解決即可贝乎。

1.2 架構(gòu)師并非算法工程師

隨著軟件系統(tǒng)規(guī)模的增加粉捻，計算相關(guān)的算法和數(shù)據(jù)結(jié)構(gòu)不再構(gòu)成主要的設(shè)計問題昧诱；當(dāng)系統(tǒng)由許多部分組成時胳搞，整個系統(tǒng)的組織巡莹，也就是所說的“軟件架構(gòu)”崭添，導(dǎo)致了一系列新的設(shè)計問題豹爹。
--《An Introduction to Software Architecture》卡內(nèi)基·梅隆大學(xué)的 Mary Shaw 和 David Garlan第股，1994 年

在我之前的文章中架構(gòu)設(shè)計00-架構(gòu)師知識體系10-對軟件認(rèn)知層次的思考中有詳細(xì)的說明代碼是由數(shù)據(jù)結(jié)構(gòu)和算法組成的酌毡，在代碼之上還有程序辆脸、軟件但校、系統(tǒng)、平臺每强、企業(yè)架構(gòu)這幾個層次始腾。所以，算法是組成軟件系統(tǒng)不可或缺的內(nèi)容空执，但算法在軟件系統(tǒng)中絕對不是主角浪箭。

根據(jù)上面mary和david所描述的由于軟件規(guī)模在不斷的擴大，架構(gòu)更多的工作用來解決規(guī)模問題辨绊。而不是算法和數(shù)據(jù)結(jié)構(gòu)問題奶栖。

1.3 架構(gòu)師并非高級程序員

架構(gòu)設(shè)計的關(guān)鍵思維是判斷和取舍， 程序設(shè)計的關(guān)鍵思維是邏輯和實現(xiàn)门坷。很多程序員在轉(zhuǎn)變?yōu)榧軜?gòu)師后宣鄙，很難一開始就意識到這個差異，還是按照寫代碼的方式去思考架構(gòu)默蚌，這樣會導(dǎo)致很多困惑冻晤。--李運華《從零開始學(xué)架構(gòu)：照著做，你也能成為架構(gòu)師》

架構(gòu)設(shè)計與軟件編程一樣绸吸，有很多中模式鼻弧、方法设江。具體使用那種模式、方法進行實施工作并不是確定的攘轩，這樣就會有優(yōu)化的架構(gòu)和粗陋的架構(gòu)叉存，優(yōu)秀的代碼和低劣的代碼之分。而對于架構(gòu)師來說設(shè)計模式度帮、架構(gòu)模式歼捏、架構(gòu)風(fēng)格在實踐中的運用就成為了判斷架構(gòu)師能力的最基本方法。優(yōu)秀的架構(gòu)師可以讓這些有機的結(jié)合并高效的解決問題笨篷。而高級開發(fā)能寫清楚設(shè)計模式已經(jīng)很不錯了瞳秽。造成這個的區(qū)別就在于決策方式與過程的不同。

1.4 架構(gòu)師并非項目經(jīng)理

項目經(jīng)理的職責(zé)是讓軟件能夠在有限的資源與時間的情況下保質(zhì)保量的交付冕屯。而架構(gòu)師為這個過程提供技術(shù)支持讓軟件能夠平順的落地寂诱。所以架構(gòu)師必須懂軟件過程過程管理，但并不是實際操作這部分內(nèi)容安聘。

1.5 架構(gòu)師并非運維工程師

很多架構(gòu)師都是運維出身的痰洒，這是不爭的事實。不過像架構(gòu)師不是高級開發(fā)一樣浴韭，運維工程師成為架構(gòu)師之后也需要思維上的轉(zhuǎn)變丘喻。需要從原先的以系統(tǒng)穩(wěn)定、系統(tǒng)性能念颈、系統(tǒng)安全而努力泉粉，轉(zhuǎn)變?yōu)檎麄€系統(tǒng)支撐、提供可行的解決方案榴芳。

2. 目標(biāo)與定位

明確了哪些不是架構(gòu)師嗡靡，這里再說明哪些是架構(gòu)師應(yīng)該持有的理念。作為架構(gòu)師實際的窟感、落地的工作是很重要的讨彼，但應(yīng)該要想清楚在實際的設(shè)計與落地過程中我們?yōu)槭裁催@樣做。應(yīng)該抱著怎樣的理念去推進我們的工作柿祈。

2.1 定位：業(yè)務(wù)與技術(shù)之間的橋梁

軟件架構(gòu)設(shè)計的最終目標(biāo)就是跨越業(yè)務(wù)需求與軟件實現(xiàn)之間的鴻溝哈误，而在跨域這個鴻溝需要做的就很多。需要想盡一切辦法滿足業(yè)務(wù)與非功能需求的同時躏嚎，還要讓實現(xiàn)團隊能夠接受設(shè)計中的復(fù)雜度蜜自，以實際可行的方式設(shè)計出架構(gòu)實現(xiàn)路徑才能有益的溝通業(yè)務(wù)團隊與技術(shù)團隊。

2.2 目標(biāo)：

就像之前評價一個公司的層次一樣：有理想卢佣、有目標(biāo)重荠、有原則、有方法虚茶，理解清楚通過具體化的目標(biāo)來實現(xiàn)定位中的內(nèi)容這樣層次遞進的方式來逐步的細(xì)化來提高可行性戈鲁。

通過適度設(shè)計來制定更加貼近實施過程的設(shè)計尾膊，并盡量的做到以推遲決策，快速決策的方式推進實施工作荞彼。以控制復(fù)雜度來理清業(yè)務(wù)與技術(shù)的復(fù)雜度，并以合理有效的方式解決實現(xiàn)過程中的復(fù)雜度待笑。做軟件研發(fā)只有一個目標(biāo)就是提供有價值的軟件鸣皂，而有價值的軟件就必須從架構(gòu)的角度服務(wù)軟件研發(fā)過程。

• 適度設(shè)計
  在馬丁富勒的《設(shè)計已死》已經(jīng)說明了適度設(shè)計的重要性暮蹂。
• 控制復(fù)雜度
  在張逸老師的《解析領(lǐng)域驅(qū)動設(shè)計》中復(fù)雜度的來源有：規(guī)模寞缝、結(jié)構(gòu)與變化。并且詳細(xì)闡述了應(yīng)對方法仰泻。
• 服務(wù)于軟件研發(fā)過程
  保證架構(gòu)設(shè)計中的元素是可以被拆分與執(zhí)行的荆陆。這一原則代表著我們可以小步的交付與驗證軟件。最主要的也是快速交付集侯，交付有效的軟件被啼。

2.3 達(dá)成目標(biāo)的方法

• 接受現(xiàn)實
  接受自己的平凡，接受自己做的事情的平凡棠枉。我們絕大多數(shù)人都是智力平凡浓体、能力平凡、精力平凡的人辈讶。不要認(rèn)為別人做不成的事我自己上手就絕對能做成命浴，在平凡人做成別人做不成的事只有一個原因就是比別人更加細(xì)心更加專業(yè)才能做成他們做不成的事情。
  巧婦難為無米之炊贱除，有投入才有產(chǎn)出生闲。只有在有實際投入的時候才能有產(chǎn)出，這句話大家都知道但是并不是所有人都能接受月幌。需要接受它并不是相信你可以打破它碍讯。就想很多三角不可能一樣，有很多人想破解它但是從理論角度已經(jīng)證明不可能的事情是不可能破解的飞醉。
  羅馬不是一天建成的冲茸，冰山之下才是關(guān)鍵。接收干起來比看起來要復(fù)雜的多也是很多人無法預(yù)先估計也無法估量的事情缅帘。但是對于我們來說需要接受轴术，并通過方法論來明確它即可。
• 消除不確定性
  從軟件實現(xiàn)的角度來看不能有模糊的內(nèi)容钦无，因為模糊了就沒有辦法去寫代碼逗栽。對于架構(gòu)來說可以模糊，因為不確定的內(nèi)容可以推遲決策失暂。所以從三個角度來消除模糊彼宠、不確定的說法：業(yè)務(wù)需求鳄虱，技術(shù)需求，管理過程凭峡。這里所有的不確定性都可以使用SMART原則來解決拙已。
• 降低業(yè)務(wù)和系統(tǒng)的復(fù)雜度
  復(fù)雜的事情對于人的認(rèn)知，解決方案的制定都是問題摧冀。所以簡化倍踪、降低復(fù)雜度是對問題更好的應(yīng)對方式，以簡化和降低復(fù)雜度為理念去實施才能真正的落地索昂。對于這方面可以參照領(lǐng)域驅(qū)動設(shè)計中的問題域與解決域之間的關(guān)系建车。
• 為團隊服務(wù)的理念
  在管理鐵三角上只有時間和范圍的調(diào)整，沒有質(zhì)量的調(diào)整椒惨。為軟件能夠按質(zhì)按量的開發(fā)并上線就得考慮進入就得保證有完整的RoadMap來保證實施過程缤至。

3. 思維方式

只有細(xì)節(jié)沒有整體，只有整體沒有細(xì)節(jié)的康谆。并不能很好的說明你是一個架構(gòu)師的思維方式领斥。以《金字塔原理》的方式來系統(tǒng)的認(rèn)識一個軟件需求才能做出有效的決策。

3.1 解決問題的方法

解決問題必須要明確問題秉宿，批判思維中有很多深入挖掘問題并分析問題的方法戒突。在定義好問題空間之后，對于問題空間的解決辦法就如《恰如其分的軟件架構(gòu)》中所給出的解決方案：

• 分解
  分解可以解決問題如下：1. 有沒有應(yīng)對未知問題的方法描睦？2. 對于軟件系統(tǒng)的業(yè)務(wù)與技術(shù)進行系統(tǒng)性的認(rèn)識才可以進行決策膊存。片面性的？ 3. 在開發(fā)過程中與運行過程中怎樣使用技術(shù)忱叭？
• 抽象
  抽象可以解決的問題如下：1. 對于業(yè)務(wù)的事務(wù)腳本式的寫法來說隔崎，怎么抽象出事務(wù)腳本中流程式的實體與關(guān)系？2. 高內(nèi)聚韵丑、低耦合在不同級別上應(yīng)該怎么實現(xiàn)爵卒？
• 知識/經(jīng)驗
  知識可以解決的問題如下：1. 最新的就是最好的嗎？

3.3 從“問題”開始撵彻，而不是“技術(shù)”

技術(shù)人員對于新技術(shù)的都有著一種與身俱來的激情钓株，總是樂于去學(xué)習(xí)新技術(shù)，同時也更有激情去使用新技術(shù)陌僵。但是這也同樣容易導(dǎo)致一個通病轴合，就是“當(dāng)我們有一個錘子的時候看什么都是釘子”，使用一些不適合的技術(shù)去解決手邊的問題碗短，常常會導(dǎo)致簡單問題復(fù)雜化受葛。
技術(shù)只是解決域中的解決工具而已，在針對不同的業(yè)務(wù)問題選擇不同解決工具是架構(gòu)師的基本能力。很多時候這個問題都會被導(dǎo)致总滩，有什么樣的技術(shù)可以解決我現(xiàn)在與到的問題纲堵，如果解決不了業(yè)務(wù)問題就不實現(xiàn)了。這其實是一個知識陷阱闰渔，從開發(fā)轉(zhuǎn)為架構(gòu)師時一個很重要的問題就是超越這個問題并解決這個問題席函。

3.2 方法論

作為中層來說并不是簡單的執(zhí)行命令就可以成為一個好的架構(gòu)師，需要有自己的決策過程與決策方法冈涧。并在決策和解決問題這兩個能力上保持有有效可實現(xiàn)的方法向挖。
使用金字塔原理 + DDD + 分解/抽象/知識可以解決問題，再配合例如：SMART炕舵、PDCA、SWOT跟畅、5W2H等方法來分析問題就可以將分析到解決了咽筋。但是決策并不是一件容易的事，我在做決策是一般的流程如下：

1. 系統(tǒng)性了解業(yè)務(wù)然后才能進行決策徊件。**
2. 分析系統(tǒng)中各個點的重要性與優(yōu)先級奸攻。
3. 根據(jù)分析結(jié)果進行權(quán)衡過程。
4. 給出解決方案并給出決策理由虱痕，并制定備用方案與決策理由睹耐。

這個過程就需要根據(jù)團隊的情況、業(yè)務(wù)的情況部翘、技術(shù)的情況等進行問題list的制定并解答硝训。來進行決策，問題例如：

1. 在團隊現(xiàn)狀的情況下新思，怎么讓這個團隊可以按照時間點實現(xiàn)出來窖梁？
2. 復(fù)雜業(yè)務(wù)是不是可以進行化簡或者簡約化？
3. 性能問題是否可以通過某項技術(shù)徹底解決夹囚，還是通過多項技術(shù)組合來解決纵刘？

4. 執(zhí)行力（知道怎么落地）

做了架構(gòu)設(shè)計之后要能將架構(gòu)落地，落地了才是好架構(gòu)荸哟。所以假哎，在落地過程中需要保證實現(xiàn)的內(nèi)容是按照設(shè)計走，并且能夠很好的按照實現(xiàn)路徑進行實現(xiàn)鞍历。在這里經(jīng)常與到的兩個問題：

1. 做正確的事舵抹，而不是容易的事。
   例如：不要讓混亂的堰燎、壞味道的設(shè)計在一個組件中因為各種原因傳遞到其他組件中掏父。
2. 步子邁的太大，是不是會扯到“淡”秆剪。
   計劃可以很小赊淑，落地爵政。不能因為壓力就在沒人，沒資源的情況下就趕著上線陶缺。

5. 溝通能力

對上要有目標(biāo)與過程钾挟，對下要有邏輯與實現(xiàn)。這樣才可以落地軟件目標(biāo)饱岸。溝通的一般原則是坦誠掺出，不帶任何歧視，有邏輯性苫费，分優(yōu)先級汤锨，對事不對人。在邏輯通順百框，保持簡單闲礼，可用很難的情況下需要說明情況并讓團隊達(dá)成共識。

6. 總結(jié)

君子和而不同铐维。認(rèn)識到一件事不同的側(cè)面理解出來的內(nèi)容是不同的柬泽，但以落地實現(xiàn)就為目標(biāo)既可以達(dá)到我們最終目標(biāo)即可。所以嫁蛇，可以容下別人的意見與建議并推動實現(xiàn)的發(fā)展才是好的實現(xiàn)锨并。
真正優(yōu)秀的架構(gòu)都是在企業(yè)當(dāng)前人力、條件睬棚、業(yè)務(wù)等各種約束下設(shè)計出來的第煮，能夠合理地將資源整合在一起井發(fā)揮出最大功效，井且能夠快速落地抑党。這也是很多 BATJH (百度空盼、阿里巴巴、騰訊新荤、京東揽趾、華為)出來的架構(gòu)師到了小公司或創(chuàng)業(yè)團隊反而做不出成績的原因，因為沒有了大公 司的平臺苛骨、資源篱瞎、積累，只是生搬硬套大公司的做法痒芝，必然會失敗俐筋。

7. 參考：

如何從架構(gòu)圖開始讓架構(gòu)設(shè)計平滑落地
為什么需要關(guān)注軟件架構(gòu)
上班第一周，怒懟CTO
微服務(wù)架構(gòu)及設(shè)計模式
開發(fā)者需要知道的有關(guān)軟件架構(gòu)的五件事
你是個軟件架構(gòu)師嗎严衬？
一位架構(gòu)師的感悟：過度忙碌使你落后