9、架構(gòu)設(shè)計需要遵循哪些規(guī)范,？

系統(tǒng)思維，系統(tǒng)分析,，系統(tǒng)設(shè)計,，架構(gòu)元素，架構(gòu)視圖,，架構(gòu)模型,，業(yè)務(wù)模型，概念模型,，系統(tǒng)模型,，分析模型，設(shè)計模型,，用例驅(qū)動,，領(lǐng)域驅(qū)動，物件,，功能,，物件結(jié)構(gòu)，功能交互,，利益,，架構(gòu)工具，決策選擇,，架構(gòu)師，架構(gòu)圖,。

軟件從業(yè)人員的成長路線大體是在管理線和技術(shù)線上形成突破,，當(dāng)然也有結(jié)合起來相得益彰的。而技術(shù)上的追求,，架構(gòu)師則是一個重要的門檻,，對于剛?cè)胄械某绦騿T可能會認(rèn)為架構(gòu)師就是畫架構(gòu)圖的，誠然架構(gòu)師很重要的一個職責(zé)是繪制架構(gòu)圖,，但這只是其中一個很小的環(huán)節(jié)而已,。而實際上架構(gòu)也只是系統(tǒng)設(shè)計里面的一個重要環(huán)節(jié)，除了架構(gòu)還包含了商業(yè)訴求,，業(yè)務(wù)建模,，系統(tǒng)分析，系統(tǒng)設(shè)計等重要領(lǐng)域,。本文嘗試從更高視角重新審視架構(gòu)設(shè)計的工作,，把架構(gòu)設(shè)計的上升到系統(tǒng)設(shè)計的立體空間去探索，最終勾勒出系統(tǒng)設(shè)計的全域知識體系,。

人類社會活動中的不管大大小小的，簡單抑或復(fù)雜的事物,，總要先出現(xiàn)在我們的腦海里,，然后再投射到現(xiàn)實的物理空間來。我們總是在孜孜不倦地追求美好的事物,，但現(xiàn)實存在的問題就是,，首先我們的腦袋也理解不了太過復(fù)雜的東西，其次腦海里的想象有時候也很難真實無損的映射成現(xiàn)實的系統(tǒng),，再者由于總是資源有限的,，我們并沒有花不完的預(yù)算。歸結(jié)起來設(shè)計一個系統(tǒng),，或者樸素的說,，做一件事情，我們需要解決以下的問題：

系統(tǒng)是由一組實體和實體之間關(guān)系構(gòu)成的集合,，其功能大于各個實體功能之和。

系統(tǒng)可以分為自然系統(tǒng)和人工系統(tǒng),，但是本文特指需要人類參與的人工系統(tǒng),。

自然系統(tǒng)：

• 人體系統(tǒng)
• 生態(tài)系統(tǒng)
• 大氣系統(tǒng)

• 水源系統(tǒng)

人工系統(tǒng)：

• 機(jī)械系統(tǒng)
• 電子系統(tǒng)
• 操作系統(tǒng)

• 社會系統(tǒng)

上面談到在系統(tǒng)設(shè)計流程主要是使用了分析思維和系統(tǒng)思維的結(jié)合，當(dāng)然人類思維還有其他的運(yùn)作模式,，比如批判思維,，創(chuàng)新思維和發(fā)散思維等,，以此衍生的又是另外一套截然不同的方法論。下面我們主要分析系統(tǒng)設(shè)計過程中的思維活動,。通常談起架構(gòu)師就會聯(lián)想到各式各樣的架構(gòu)圖,，談架構(gòu)圖就要搞清楚什么是架構(gòu)設(shè)計，那么架構(gòu)設(shè)計之前是什么呢,？架構(gòu)設(shè)計是整個系統(tǒng)建設(shè)的核心環(huán)節(jié),，猶如設(shè)計圖紙之于建筑那么重要，那架構(gòu)設(shè)計之上應(yīng)該就是系統(tǒng)設(shè)計了,。先搞清楚系統(tǒng)設(shè)計的定義：

系統(tǒng)設(shè)計是根據(jù)系統(tǒng)分析的結(jié)果,，運(yùn)用系統(tǒng)科學(xué)的思想和方法，設(shè)計出能最大限度滿足所要求的目標(biāo)系統(tǒng)的過程,。

業(yè)務(wù)描述

上節(jié)弄清楚系統(tǒng)的概念,，也就是先把邊界框定下來，那么我們要實現(xiàn)的無非就是以上類別的系統(tǒng),。自然系統(tǒng)是天然形成的,，或者你愿意的話也可以認(rèn)為是盤古開天辟地形成的，那也可以歸為人為系統(tǒng),。我這么說的原因是嘗試把視角從軟件這個領(lǐng)域往更加宏觀的方向提升,，讓我們暫時忘掉軟件架構(gòu)師這一根深蒂固的角色。

假設(shè)現(xiàn)在我們想登上火星,，言下之意是需要借助一套設(shè)備要把人類送到火星上,，大膽一點，發(fā)揮僅存那點為數(shù)不多的物理知識儲備,，要設(shè)計出一套系統(tǒng),，能夠把人類送到火星。這個時候老板就是愿意出資去火星豪華7日游的金主,，那么需要一個負(fù)責(zé)人來實現(xiàn)這趟旅程,，我們姑且把這個負(fù)責(zé)人就稱為登火旅行系統(tǒng)架構(gòu)師（叫總設(shè)計師也行，不需要在意這種細(xì)節(jié)）,。那么這個系統(tǒng)架構(gòu)師的工作,，就是把登陸火星的一系列需求和目標(biāo)轉(zhuǎn)化成為足于支撐登陸火星龐大工程的系統(tǒng)架構(gòu)。

根據(jù)系統(tǒng)總覽提到的問題,，先一一作答,。

業(yè)務(wù)流程畫圖元素：火箭,，機(jī)艙,，地球，火星,，來回,，基礎(chǔ)功能（安全，舒適,，成本）

通過以上的描述,，基本涵蓋了火星旅程的四個階段：登機(jī)，航行,，下機(jī)游玩,，返程，這本質(zhì)上跟我們平時搭個飛的去趟浪漫的土耳其也是差不多的,。而在此之前我們腦海里可能還是一片混沌,，沉溺在登陸火星這項浩瀚的工程而不知道從而入手。從混沌到開始有點頭緒,，其實無形中已經(jīng)完成了一次建模,，我們稱為業(yè)務(wù)建模。翻回去查閱系統(tǒng)總覽的表格,，其實我們已經(jīng)把需求這個維度大致列舉出來了,，把登陸火星的幾大領(lǐng)域給分離開來了。那么接下來就是要把登陸火星這個項目的主線給說明清楚,。

概念抽象

怎樣把這件事的主線說明清楚,？滔滔不絕的把一件事情講完其實反而是很難講明白,，除非這件事情本身足夠非常簡單的。那么就需要抓重點的來說,，這個時候就需要一個叫做“概念”的工具,。

概念是抽象的、普遍的想法,，是充當(dāng)指明實體,、事件或關(guān)系的范疇或類的實體。

簡單來說,，概念就是用簡單的一個詞匯,，就可以讓在座的大家都能準(zhǔn)確無誤的理解這個詞匯所表達(dá)的含義。這個是語言獨(dú)特的魅力,，可以說有個概念這個武器,，才有了人類多次工業(yè)革命的文明大爆發(fā)。有了“概念”這個工具,，再對概念進(jìn)行組合,，會爆發(fā)出無窮的生產(chǎn)力。

這里穿插講一下概念的應(yīng)用,，比“傅立葉級數(shù)”這個概念,，我敢打賭有80%的人不知道所謂何物，但是沒關(guān)系,，我們并不是要來科普這個概念,，先根據(jù)百度百科來看看這個概念的描述：

若在整個數(shù)軸上:

且等式右邊級數(shù)一致收斂，則有如下關(guān)系式:

一般地說,，若 是以 為周期且在上可積的函數(shù) ,，則按上式計算出的稱為函數(shù)(關(guān)于三角函數(shù)系)的傅里葉系數(shù)，以的傅里葉系數(shù)為系數(shù)的三角級數(shù)稱為(關(guān)于三角函數(shù)系)的傅里葉級數(shù),，記作：

其中,，記號“”表示上式右邊是左邊函數(shù)的傅里葉級數(shù)

先不要怕，我這么說的目的不是為了讓大家搞懂什么是傅立葉級數(shù),，這里我們可以看出即使這么鬼畜概念也是很普通的基礎(chǔ)概念元素組成的,，比如收斂公式，比如三角函數(shù),，比如Σ求和概念,，甚至像1，2,，3這些阿拉伯?dāng)?shù)字,。這里不得不說學(xué)數(shù)學(xué)最核心的環(huán)節(jié)就是深刻理解概念，沒有之一。說回來,，這里的語境就是在大家都共同理解接受這些基礎(chǔ)概念后,，經(jīng)過一系列復(fù)雜組合的高級概念，也依然能夠清晰嚴(yán)謹(jǐn)?shù)谋磉_(dá)出來,，下面傅里葉級數(shù)的產(chǎn)生過程的動圖看看就好,。

好了，現(xiàn)在我們知道了概念這個工具的重要性和功能,，前面我們已經(jīng)列舉了登陸火星要做的事情,，那么現(xiàn)在就需要精確簡潔的把這件事給說清楚了，這個是個困難的任務(wù),，因為如果主線沒有梳理清晰，后面整個工程將萬劫不復(fù),。

在業(yè)務(wù)建模后就是概念建模,，作為架構(gòu)設(shè)計的輸入，這個階段就需要對核心業(yè)務(wù)的充分理解,，同時在基礎(chǔ)性和通用性方面的功能也需要同時考慮,，這個階段需要大量的業(yè)務(wù)專家和各個領(lǐng)域的科學(xué)家通力協(xié)作，保證對系統(tǒng)的理解沒有偏差,。經(jīng)過一系列的概念抽象和組合,，最終輸出登陸火星工程的架構(gòu)圖，這里只是用于說明登陸火星項目同樣遵循這業(yè)務(wù)-概念-架構(gòu)-設(shè)計的流程,，不要在意架構(gòu)圖本身合不合理,。

系統(tǒng)落地

當(dāng)然這還遠(yuǎn)遠(yuǎn)不夠，系統(tǒng)之所以復(fù)雜,，就是我們對系統(tǒng)總有無數(shù)更多的要求,，更多的功能，更好的性能,，那么接下來就是對各個模塊進(jìn)行分析,，細(xì)化，設(shè)計和實施,。當(dāng)然我們不會班門弄斧真的在這里去分析登陸火星的實際流程,，以上這個例子雖然比較粗曠，但是基本也描繪了一個復(fù)雜系統(tǒng)建設(shè)的過程,，也就是從需求,，建模到架構(gòu)的思維過程，是從最原始的登火需求一步步擴(kuò)展的過程,。其實我們還可以舉個小一點的案例,，比如一個有趣的需求“賺錢”，引申出來就是做一個能盈利商業(yè)項目架構(gòu)，的有興趣的同學(xué)可以根據(jù)這個思維模式一步一步勾畫出整個流程出來,，相信對這是也不錯的方法,，也許還真能解決些許困惑。下面演示的就是登月過程宏觀層面落地的步驟,。

架構(gòu)目標(biāo)

一直以來我聽過很多人在講架構(gòu),，有些人在做架構(gòu)，但是很難討論出一個大家都滿意的定義,，什么是架構(gòu)師,，架構(gòu)師需要做哪些工作？或者說很少有往深的去思考,，只知道被稱為架構(gòu)師說明這個人很厲害,。在我畢業(yè)的時候有個同學(xué)打趣的跟我說，你們做程序的無非就是增刪改查,，當(dāng)時我竟無言以對,，當(dāng)時腦海里浮現(xiàn)的是一系列工具的應(yīng)用技巧，比如tomcat,，nginx的使用,，還有對業(yè)務(wù)的翻譯。隨著對業(yè)務(wù)的貼近和對計算機(jī)技術(shù)的進(jìn)一步認(rèn)識,，我重新審視“這世上的系統(tǒng)無非就是增刪改查”,，這句話說對也對也不對，這句話就跟計算機(jī)軟件無非就是0和1的集合,，也對也不對,。特別是對剛?cè)胄械娜丝赡苡X得設(shè)計離自己比較遠(yuǎn)，因為習(xí)慣了打開idea才開始考慮業(yè)務(wù),，寫代碼才開始思考領(lǐng)域模型,，這是非常不好的習(xí)慣，好像如果沒有在coding狀態(tài)下是無法進(jìn)行建模思考,，這個很難,，需要持久的訓(xùn)練才能達(dá)成設(shè)計階段進(jìn)行思考。架構(gòu)設(shè)計只是系統(tǒng)設(shè)計里面的一個階段,，而系統(tǒng)設(shè)計是應(yīng)用建設(shè)里面的核心環(huán)節(jié),，有一些簡單的應(yīng)用建設(shè)是不需要系統(tǒng)設(shè)計的，當(dāng)然有一些復(fù)雜的應(yīng)用,，在能力超強(qiáng)的工程師團(tuán)隊,，有足夠的默契后，也可以直接進(jìn)行建設(shè),。

軟件架構(gòu)之道最核心的問題是解決復(fù)雜性的問題,，并且在解決問題的過程中找到最佳的平衡點,，既要簡單又能滿足發(fā)展。描述系統(tǒng)設(shè)計的本質(zhì),，就是實現(xiàn)縱向上的時間,，橫向上的空間進(jìn)行考慮,，規(guī)劃出決策路徑,，最終拿到目標(biāo)結(jié)果,。架構(gòu)師眼里第一件事不是多流行的技術(shù),，多高性能的框架，或者多完善的業(yè)務(wù)模型,，而應(yīng)該聚焦在利益之上,。對,，這個可能會顛覆一些認(rèn)知,，當(dāng)我們真正把利益放在首位后,，再去考慮接下來要完成的事情，我們的工作才能稱得上架構(gòu),。也就是說,，架構(gòu)師的天職就是最大限度的實現(xiàn)客戶的利益，這里的客戶可以是市場客戶,，也可以是協(xié)作團(tuán)隊，還可以是同一個團(tuán)隊的項目成員,。再直白的說,，架構(gòu)師就是負(fù)責(zé)把老板畫的餅給實現(xiàn)了，在相當(dāng)長的一段時間內(nèi)保證產(chǎn)物有足夠的利益回報,。有人會說那我們做的就是公益項目,，就不考慮利益，那我我補(bǔ)充一下,，這里說的利益不止是經(jīng)濟(jì)收益,，還有系統(tǒng)帶來的社會價值。那么又有人會說,，架構(gòu)是追求利益回報,，那老板的目標(biāo)就是炒股發(fā)大財，請架構(gòu)師你給我選幾支股票吧,，那我會說其實優(yōu)秀的基金經(jīng)理也可以稱為廣義上的架構(gòu)師,。

架構(gòu)過程

自然在增熵，而系統(tǒng)架構(gòu)過程其實就是減熵的過程,，一個架構(gòu)的誕生始于目標(biāo)的確立,，然后對需求的刻畫，繼而是落地方法的抉擇,。所謂條條大路通羅馬,，有的是一路平川而有的則是崎嶇不平,，那么架構(gòu)過程就是不斷歸類合并同類項，力求最合適的決策選擇來實現(xiàn)我們所要達(dá)成的愿望,。在面對復(fù)雜業(yè)務(wù)的場景下,，我們需要做出如下的思考：

• 確定系統(tǒng)實體對象和預(yù)期功能
• 抽象系統(tǒng)實體之間的關(guān)系，功能與實體的關(guān)系
• 劃定系統(tǒng)的邊界和外部環(huán)境的關(guān)系

• 預(yù)測系統(tǒng)帶來的效果

在架構(gòu)過程很重要的一項任務(wù)就是識別系統(tǒng)的實體關(guān)系和功能關(guān)系,，進(jìn)而對系統(tǒng)效果進(jìn)行預(yù)測,，也就是在完一系列的分析建模工作后推導(dǎo)出來的系統(tǒng)架構(gòu)需要在預(yù)測上達(dá)到我們要的效果，那么系統(tǒng)預(yù)測通常有如下四種方式：

• 經(jīng)驗
• 實驗
• 建模
• 推理
  

系統(tǒng)思維

系統(tǒng)思維不等于系統(tǒng)化思考,，與系統(tǒng)思維并列的可以是批判思維,，分析思維，創(chuàng)新思維,，而我們追求的是元認(rèn)知,，也即是認(rèn)識到自己處于何種思維模式。系統(tǒng)思維目標(biāo)：

• 理解系統(tǒng)是什么
• 預(yù)測系統(tǒng)的走向

• 為決策提供知識支持

系統(tǒng)思維首先是高效的理解分析現(xiàn)存的系統(tǒng),，對系統(tǒng)重構(gòu)做好理論指導(dǎo)基礎(chǔ),。

這一節(jié)介紹了設(shè)計一個系統(tǒng)需要經(jīng)歷哪些重要的環(huán)節(jié)，并且強(qiáng)調(diào)了謀求利益是系統(tǒng)設(shè)計的核心訴求,。然后通過登陸火星這項任務(wù)把一個龐大的工程變成了可理解的獨(dú)立步驟,，并且還有模有樣的畫出了架構(gòu)圖，體現(xiàn)了對業(yè)務(wù)建模到架構(gòu)輸出的流程,。下面章節(jié)我們將會展開來介紹一套核心的方法論,，如何破局系統(tǒng)架構(gòu)設(shè)計。

上一節(jié)談?wù)摿讼到y(tǒng)設(shè)計的心智模型和投射到物理世界的演化規(guī)律,，但前提是建立在已經(jīng)具備豐富系統(tǒng)設(shè)計經(jīng)驗基礎(chǔ)上。而在進(jìn)行系統(tǒng)架構(gòu)之前,，需要先對系統(tǒng)分析有一定的理解,，好比我們制造發(fā)動機(jī)之前，得先把發(fā)動機(jī)拆下來好好研究一番,，直接上來就要設(shè)計出發(fā)動機(jī)有點像空中樓閣,。本節(jié)講提供一套基礎(chǔ)的方法，來對現(xiàn)有系統(tǒng)進(jìn)行分析,，得出一些系統(tǒng)架構(gòu)相關(guān)的推論,。按照慣例需要先搞清楚系統(tǒng)分析的概念：

系統(tǒng)分析，旨在研究特定系統(tǒng)結(jié)構(gòu)中各部分的相互作用,，系統(tǒng)的對外接口與界面,，以及該系統(tǒng)整體的行為、功能和局限,，從而為系統(tǒng)未來的變遷與有關(guān)決策提供參考和依據(jù),。系統(tǒng)分析的經(jīng)常目標(biāo)之一,，在于改善決策過程及系統(tǒng)性能，以期達(dá)到系統(tǒng)的整體最優(yōu),。

大到銀河系,，小至原子粒子都有著特有的結(jié)構(gòu)，何謂結(jié)構(gòu)：

結(jié)構(gòu)是指在一個系統(tǒng)或者材料之中,，互相關(guān)聯(lián)的元素的排列,、組織關(guān)系

而系統(tǒng)在物質(zhì)世界里面當(dāng)然也遵循這樣的規(guī)則，分析系統(tǒng)跟分析銀河系也一樣,，需要對它的組成元素和元素之間的關(guān)系進(jìn)行分析,。而對系統(tǒng)的分解也是講究方法的，可以參考以下總結(jié)的一些方向：

• 體系歸納
• 層級分解
• 邏輯關(guān)系
• 自頂向下
• 自底向上
• 由外向內(nèi)

• 由內(nèi)而外

實體指系統(tǒng)物理時空存在的單元,，彼此通過一定的結(jié)構(gòu)形成系統(tǒng),，那么在分析實體之前，我們可以帶著下面的問題進(jìn)行分析：

• 系統(tǒng)是什么,？
• 構(gòu)成系統(tǒng)的元素有哪些,？
• 系統(tǒng)元素之間的結(jié)構(gòu)是什么？
• 系統(tǒng)的邊界在哪里,？

• 系統(tǒng)的使用場景是什么,？

實體是系統(tǒng)的一項基礎(chǔ)屬性，是系統(tǒng)的物理體現(xiàn)或信息體現(xiàn),。對功能的執(zhí)行起工具性作用,，而描述實體通常可以使用以下工具來表達(dá)：

• 文字描述
• 符號描述
• 插圖
• 插畫
• 示意圖
• 三維圖

• 透視圖

實體之間的關(guān)系就是結(jié)構(gòu),，分析結(jié)構(gòu)時需要對實體進(jìn)行分解，實體可以建模為對象以及象之間的結(jié)構(gòu),，進(jìn)一步可以分解為小的實體,，又可以聚合起來稱為系統(tǒng)本身，對實體之間的各種結(jié)構(gòu)分析則可以得出系統(tǒng)架構(gòu),，即是把功能元素組合成物理塊時所用的編排方式

分析實體

• 對實體的載體進(jìn)行抽象聚類,，形成對象，體現(xiàn)出邊界

• 用適當(dāng)?shù)膶哟蝸矸纸饧軜?gòu)的實體

分析關(guān)系

也即是實體的結(jié)構(gòu),，是對象之間存在穩(wěn)定關(guān)系,，有助于功能交互的執(zhí)行系統(tǒng)實體有如下關(guān)系：

• 空間拓?fù)潢P(guān)系
• 連接性關(guān)系
• 地址關(guān)系
• 順序關(guān)系
• 成員關(guān)系
• 所有權(quán)關(guān)系

• 人際關(guān)系

上面一節(jié)我們了解了系統(tǒng)的物理基礎(chǔ)，對組成系統(tǒng)的實體進(jìn)行分解,，分析,，進(jìn)而對實體的關(guān)系描述為結(jié)構(gòu)，對結(jié)構(gòu)抽象是得出架構(gòu)的基礎(chǔ)步驟,，而系統(tǒng)物理基礎(chǔ)存在的理由是為了實現(xiàn)我們的訴求,，也即是系統(tǒng)的功能,。畢竟萬物皆有因，存在即合理,，系統(tǒng)構(gòu)建最終也是要達(dá)成我們的意愿,，完成這個訴求才算是合格的架構(gòu)。分析形式相對來說畢竟簡單,，畢竟實體是有形的便于理解,，而功能則是由實體組合涌現(xiàn)出來的屬性，功能分析過程需要跟實體不斷的交互穿插,。

關(guān)于系統(tǒng)功能其實可以樸素的認(rèn)為就是動賓短語的集合,，功能=動詞+賓語，含義就是實體狀態(tài)變化的過程,，就是功能的體現(xiàn),，具體分析下文會詳細(xì)展開。

功能 = 主體 + 操作 + 操作對象,，比如嘴巴有“吃飯”功能,，飛機(jī)有“搭載乘客”功能，報表平臺有“展示報表”功能,。

操作：對象經(jīng)歷的一種轉(zhuǎn)換模式,，過程設(shè)計操作數(shù)的狀態(tài)變化。

操作對象：操作數(shù)是一個對象,，在某段時間內(nèi)穩(wěn)定且無條件存在,，操作數(shù)不需要先于功能的執(zhí)行而存在，操作數(shù)可能會由功能中的過程部分來創(chuàng)建,，修改或消耗,。

總結(jié)起來，系統(tǒng)分析就是建立一套方法論,，去分析復(fù)雜的系統(tǒng),，令系統(tǒng)不再那么難懂。

經(jīng)過了上幾節(jié)的思維訓(xùn)練和系統(tǒng)逆向分析,，我們也大概理解了系統(tǒng)設(shè)計的流程和系統(tǒng)架構(gòu)的形成過程，本節(jié)正向介紹系統(tǒng)設(shè)計,，包括設(shè)計工具,，需求分析，模型建立,，架構(gòu)推導(dǎo),，設(shè)計規(guī)范完整的系統(tǒng)設(shè)計流程。系統(tǒng)設(shè)計,，也即是設(shè)計出一套良好的系統(tǒng)架構(gòu),，就是構(gòu)建一套具備必要復(fù)雜度又不難懂的系統(tǒng),。下面在介紹方法輪的同時，同時會穿插一個數(shù)據(jù)平臺的大致設(shè)計過程,。

在進(jìn)入本章節(jié)系統(tǒng)設(shè)計前,，我們先要來學(xué)習(xí)學(xué)習(xí)一個架構(gòu)TOGAF：

TOGAF：框架開放組體系結(jié)構(gòu)框架（The Open Group Architecture Framework，縮寫：TOGAF）是一個企業(yè)架構(gòu)框架,，它提供了一種設(shè)計,，規(guī)劃，實施和管理企業(yè)信息技術(shù)架構(gòu)的方法,。TOGAF是一種高層設(shè)計方法,。它通常被建模為四個級別：業(yè)務(wù)，應(yīng)用程序,，數(shù)據(jù),，和技術(shù)。

在TOGAF中,，任何一種企業(yè)能力的建設(shè)都需要對如下四種領(lǐng)域進(jìn)行設(shè)計,，包括針對這一可持續(xù)性架構(gòu)實踐建設(shè)：

• 業(yè)務(wù)架構(gòu)：突出了架構(gòu)治理、架構(gòu)流程,、架構(gòu)組織結(jié)構(gòu),、架構(gòu)信息需求以及架構(gòu)產(chǎn)品等方面
• 數(shù)據(jù)架構(gòu)：定義了組織中架構(gòu)連續(xù)體和架構(gòu)資源庫的結(jié)構(gòu)
• 應(yīng)用架構(gòu)：描述了用于支持此可持續(xù)架構(gòu)實踐的功能和服務(wù)

• 技術(shù)架構(gòu)：描述了架構(gòu)實踐中用于支持各架構(gòu)應(yīng)用和企業(yè)連續(xù)體的基礎(chǔ)設(shè)施需求和部署方式

TOGAF架構(gòu)框架是一組工具，可用于開發(fā)各種不同的架構(gòu)：

• 描述了一種用于根據(jù)一組構(gòu)建塊來定義信息系統(tǒng)的方法
• 展示構(gòu)建塊如何組合在一起
• 包含一組工具
• 提供共同的詞匯集合
• 包括推薦標(biāo)準(zhǔn)列表

• 包括可用于實現(xiàn)構(gòu)建塊的兼容產(chǎn)品列表

企業(yè)可以通過應(yīng)用企業(yè)架構(gòu)開發(fā)方法（ADM）來為建設(shè)各種業(yè)務(wù)能力,，然后我們再來介紹另外一種系統(tǒng)設(shè)計的思路,。

工欲善其事，必先利其器,。前文講到思維分析,，不同思維模式?jīng)Q定不同的方法論，那么在分析思維層面,，人類大腦其實很難理解太過復(fù)雜的東西,，這個時候就需要借助一些工具來協(xié)助思維的活動。首先第一工具當(dāng)然是語言,，這個不用多說,，沒有語言作為基礎(chǔ)將寸步難行,，單個體的時候語言用于描述系統(tǒng)的訴求,，而多個體的時候語言則扮演著溝通的角色，但是如果語言不互通的話可能就像雞同鴨講,。即使是同一種語言,，不同的表述都會形成很大的偏差，那么就需要一種普遍認(rèn)可的統(tǒng)一語言,，在系統(tǒng)分析審計領(lǐng)域,，我們首推統(tǒng)一建模語言（英語：Unified Modeling Language,，縮寫 UML），當(dāng)然還有其他比如SYSML或者OPM,，下面我們先大致介紹下UML,，列出UML的核心語言元素，視圖,，模型和過程,。

核心元素

• 參與者
• 用例
• 邊界
• 業(yè)務(wù)實體
• 包
• 分析類
• 設(shè)計類
• 關(guān)系
• 組件

• 節(jié)點

核心視圖

靜態(tài)圖包括：

• 用例圖
• 類圖

• 包圖

動態(tài)圖包括：

• 活動圖
• 狀態(tài)圖
• 時序圖
• 協(xié)作圖

• 泳道圖

核心模型

• 業(yè)務(wù)用例模型
• 概念用例模型
• 系統(tǒng)用例模型
• 業(yè)務(wù)領(lǐng)域模型
• 系統(tǒng)分析模型
• 系統(tǒng)設(shè)計模型

• 系統(tǒng)組件模型

核心流程

• 業(yè)務(wù)建模
• 系統(tǒng)建模
• 模型分析

• 模型實施

軟件工具

• draw.io
• StarUML

• Visual Paradigm

本節(jié)不打算講需求分析師的工作流程，因為我們已經(jīng)很熟悉需求分析師對需求的分析過程了,，所以無需多言,，在講需求之前我們先來看看架構(gòu)師需要完成的工作。架構(gòu)師并不是全能的通才,，無法面面俱到的了解所有細(xì)致的需求,，那么架構(gòu)師要做的就是簡化系統(tǒng)的復(fù)雜度，消除業(yè)務(wù)歧義,，致力于輸出健壯兼容的系統(tǒng)架構(gòu),。由于系統(tǒng)需求分析需要由架構(gòu)師這個角色全程參與，深度理解業(yè)務(wù),，下面我們簡單對架構(gòu)師角色進(jìn)行討論,。

架構(gòu)角色

我們先看看傳統(tǒng)系統(tǒng)設(shè)計兩大核心角色的定義：

系統(tǒng)架構(gòu)師：是在信息系統(tǒng)研發(fā)中，負(fù)責(zé)依據(jù)需求來確定主要的技術(shù)選擇,、設(shè)計系統(tǒng)的主體框架結(jié)構(gòu),，并負(fù)責(zé)搭建實施的人。

系統(tǒng)分析師：是在信息系統(tǒng)研發(fā)中,，負(fù)責(zé)通過需求分析確認(rèn)系統(tǒng)的需求,，并進(jìn)而形成系統(tǒng)產(chǎn)品設(shè)計的人。通常他們也會涉及可行性評估,、項目管理,、開發(fā)前評估、需求驗證等工作,。

傳統(tǒng)意義的系統(tǒng)開發(fā)分為系統(tǒng)架構(gòu)師和系統(tǒng)分析師兩個角色,，但是隨著互聯(lián)網(wǎng)的快速發(fā)展，如今系統(tǒng)建設(shè)越來越趨向兩個角色結(jié)合起來,，那么互聯(lián)網(wǎng)時代架構(gòu)師有如下職責(zé)：

• 了解問題領(lǐng)域,，消除歧義
• 樹立業(yè)務(wù)目標(biāo)，抽象業(yè)務(wù)用例
• 完成涉眾分析,，發(fā)現(xiàn)系統(tǒng)主要受益者
• 劃清系統(tǒng)邊界,，確立對外交互方式
• 劃分優(yōu)先級別，聚焦系統(tǒng)核心訴求
• 分析業(yè)務(wù)需求，輸出業(yè)務(wù)模型
• 抽象業(yè)務(wù)概念,，輸出概念模型
• 推導(dǎo)系統(tǒng)架構(gòu),，輸出架構(gòu)模型

• 負(fù)責(zé)技術(shù)選型，完成系統(tǒng)落地

架構(gòu)師是軟件開發(fā)活動中的眾多角色之一,，它可能是一個人,、一個小組，也可能是一個團(tuán)隊,，我們分析的是架構(gòu)師這個角色,，能勝任這個角色的才是架構(gòu)師，那么在這個角色上能做得更加出色的就是好的架構(gòu)師,。以上架構(gòu)師職責(zé)是整體上的描述,，在細(xì)分領(lǐng)域有不同的分類。微軟對架構(gòu)師有一個分類參考,，我們參考一下,，他們把架構(gòu)師分為4種：

• 企業(yè)架構(gòu)師EA(Enterprise Architect)
• 基礎(chǔ)結(jié)構(gòu)架構(gòu)師IA(Infrastructure Architect)
• 特定技術(shù)架構(gòu)TSA(Technology-Specific Architect)

• 解決方案架構(gòu)師SA (Solution Architect)

既然對架構(gòu)師角色有諸多要求，那么也可以來歸納一下架構(gòu)師必備的一些技能,，架構(gòu)師能力要求：

• 現(xiàn)有資源評估盤點及資源編排能力
• 消除歧義分清問題主次能力
• 業(yè)務(wù)簡化描述,，用例抽象思維
• 通用市場法務(wù)市場領(lǐng)域基礎(chǔ)常識
• 業(yè)務(wù)分析架構(gòu)推導(dǎo)能力
• 計算機(jī)基礎(chǔ)理論知識體系
• 通用技術(shù)棧原理認(rèn)知
• 工具使用熟練，排查定位問題能力
• 技術(shù)深度廣度
• 分布式高并發(fā)性能調(diào)優(yōu)技能

• 產(chǎn)品思維

利益分析

首先當(dāng)然是要確立好客戶,，所謂客戶第一,，聽起來很簡單，如果只是單一的服務(wù)好客戶,，那確實不算很難,。難的是如果同時存在多個業(yè)務(wù)方向的客戶，而且客戶直接的利益產(chǎn)生交集,，而且存在矛盾,，怎么權(quán)衡好利益分配，區(qū)分客戶利益優(yōu)先級,，才是困難的,。

不忘初心這一點尤為難得，很多項目做著做著就偏離了當(dāng)初的目標(biāo),，這個過程我們一定要緊緊抓住系統(tǒng)最重要的受益者,，梳理好系統(tǒng)眾多涉眾的利益分配。

資源評估

資源評估不僅僅是項目經(jīng)理的事,，而是對團(tuán)隊資源的評估和編排,，比如某項業(yè)務(wù)技術(shù)團(tuán)隊中研發(fā)和數(shù)據(jù)人員的配比，決定了數(shù)據(jù)平臺投入的資源范圍,，這要求架構(gòu)師在做設(shè)計分析的時候需要充分考慮的資源的利用效率,，包括人力資源和機(jī)器等資源,。

需求規(guī)范

用戶的訴求體現(xiàn)為需求的輸出過程,，不同層次分解需求得出了不同的復(fù)雜度,，我們知道架構(gòu)師的一項重要職責(zé)就是消除歧義，精準(zhǔn)的把握需求來匹配用戶的訴求,。那么就需要一系列規(guī)范來保障需求采集的過程中不失真,。下面列出了需求采集過程的一些指導(dǎo)原則

• 每個軟件需求是否都有唯一的標(biāo)識符？
• 每個軟件需求都可以驗證嗎,？（如果可能,，是否可正規(guī)化，量化）
• 是否對每個軟件要求進(jìn)行了優(yōu)先排序,？
• 所有不穩(wěn)定的軟件要求是否都已標(biāo)明,？
• 軟件需求是否完整？（涵蓋了所有用戶要求,，考慮了所有相關(guān)的輸入情況）
• 軟件要求是否一致,？
• 是否明確指出了軟件需求之間的重疊交叉？
• 是否明確規(guī)定了初始系統(tǒng)狀態(tài),？
• 軟件需求是否表達(dá)了邏輯模型,， 而不是實現(xiàn)形式？
• 軟件需求是否以結(jié)構(gòu)化的方式表示為抽象層次,？
• 是否足夠清楚,，邏輯模型的結(jié)構(gòu)
• 軟件要求是否已正式形式化？
• 是否已證明軟件需求的關(guān)鍵屬性,？
• 所有形式化的圖表材料是否都隨附了充足解釋性文字,？

• 是否針對項目團(tuán)隊缺乏經(jīng)驗的領(lǐng)域描述了探索性原型？

需求描述

在進(jìn)行需求描述時,，我們可以從多個角度來審視需求是否合理的表達(dá)出來：

• 滿足需求,，能帶來什么價值，符合什么利益訴求
• 需求無法滿足時,，會帶來什么危害,，有何潛在風(fēng)險
• 需求是否緊迫，必須在什么時間段內(nèi)完成
• 多個需求直接是否產(chǎn)生耦合,，完成一個需求后是否帶來了新的問題

• 是否能多個備選方案來完成需求

需求采集

回到我們平臺設(shè)計的案例上,，經(jīng)過用戶訪談粗略的采集的需求：

· 提升經(jīng)分一鍵化能力

需求分析：

· 現(xiàn)在是配置報表case by case完成的，需要對由相同特性的報表實現(xiàn)一鍵生成

需求背后：

· 可以更快的看到數(shù)據(jù)

所以,，這個真的是客戶想要的嗎,？整體上，用戶想看什么數(shù)據(jù),？同時我也在思考下面的問題：

• 深入分析用戶需求
• 搞清楚我們的客戶是誰,？
• 定義好問題，搞清楚問題的本質(zhì),，分析問題矛盾之處,，我們要解決什么問題？
• 我們要在多大范圍內(nèi)去解決問題,，要解決跨度多長時間可預(yù)計的問題,？
• 我們的邊界在哪里？

• 我們的使命是什么,？有了使命后再談我們自己,，愿景是什么？

在系統(tǒng)設(shè)計這個階段,，我們已經(jīng)介紹了如何運(yùn)用工具,，還有用戶需求的管理，接下來就是要把需求“消化”成我們需要的架構(gòu),。但是架構(gòu)不是平白無故就產(chǎn)生的,，前文我們用登陸火星的案例也大概描述了系統(tǒng)的建設(shè)過程，那么在推導(dǎo)出架構(gòu)之前,，把用戶的不那么清晰的訴求轉(zhuǎn)化成嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)概念模型就很有必要了,。

模型基礎(chǔ)

首先我們要搞清楚模型相關(guān)的概念：

模型：是指用一個較為簡單的東西來代表另一個東西。

科學(xué)模型：是科學(xué)研究中對一類研究方法的通稱,，使用數(shù)學(xué)公式,、電腦模擬或簡單的圖示來表示一個簡化的自然界，透過分析這個模型,，以期能夠進(jìn)一步了解科學(xué),，包括說明、驗證假說,、或分析資料,。

概念模型：是用一組概念來描述一個系統(tǒng)，或用任何代替的形式來描述一個概念,，以期能進(jìn)一步了解或說明事物的運(yùn)作原理,。具體的形式可能包括思想實驗、數(shù)學(xué)模型,、電腦模擬,、示意圖,、比例模型等。

業(yè)務(wù)建模：是以軟件模型方式描述企業(yè)管理和業(yè)務(wù)所涉及的對象和要素,、以及它們的屬性,、行為和彼此關(guān)系，業(yè)務(wù)建模強(qiáng)調(diào)以體系的方式來理解,、設(shè)計和構(gòu)架企業(yè)信息系統(tǒng)。

建模目標(biāo)

也即是說業(yè)務(wù)建模是一種建模方法的集合,，目的是對業(yè)務(wù)進(jìn)行建模,。這方面的工作包括了對業(yè)務(wù)流程建模，對業(yè)務(wù)組織建模,，改進(jìn)業(yè)務(wù)流程,，領(lǐng)域建模等方面。針對復(fù)雜難懂的系統(tǒng),，我們構(gòu)造出一個比較簡單的模型,，來代表復(fù)雜的業(yè)務(wù)，這個是一種有效的辦法,，這也是我們需要建模的原因,，隨著計算機(jī)的飛速發(fā)展，或許以后計算機(jī)可以幫人類承當(dāng)一部分的設(shè)計工作,，而計算機(jī)是不怕復(fù)雜業(yè)務(wù)的,，也許那個時候就不再需要這種特地適應(yīng)人類思考的模型了。

建立模型不是最終目的,，而是把復(fù)雜的業(yè)務(wù)訴求構(gòu)建成簡單的業(yè)務(wù)概念,，在軟件開發(fā)團(tuán)隊溝通過程中能形成共識，消除歧義,，而且信息傳遞不失真,，為輸出架構(gòu)奠定基礎(chǔ)。

模型分類

在業(yè)務(wù)不同的階段,，通常會使用不用的模型來表達(dá),，一般情況下我們把模型分為：

• 業(yè)務(wù)模型
• 概念模型
• 系統(tǒng)模型
• 分析模型
• 設(shè)計模型

• 物理模型

建模方法

建模有很多種方法，對于同樣的問題域使用不同的建模手段得到的模型可能也不盡相同,。建模是一種對現(xiàn)實事件的抽象,，不同的心智會產(chǎn)生不同的模型，比如宗教,，不同宗教就是對人生觀世界觀產(chǎn)生不同的模型,，我們先介紹常用的建模方法：

• 領(lǐng)域驅(qū)動（DDD）
• 用例驅(qū)動（UDD）
• 四色建模
• CRC建模

• CQRS建模

下面我們以用例驅(qū)動和領(lǐng)域驅(qū)動為案例來介紹這兩種思維方式的建模過程。

用例驅(qū)動

用例驅(qū)動是一種由外而內(nèi),，先招式后內(nèi)功的思想,。我們先從涉眾對系統(tǒng)的期望開始,，定義出系統(tǒng)如何滿足他們的愿望。這一過程是感性的,、外在的,、符合當(dāng)前需求的。用例驅(qū)動的結(jié)果是我們的軟件是以實現(xiàn)一個個場景為目的的,，認(rèn)為當(dāng)一個系統(tǒng)的行為滿足了所有涉眾的期望之后,，即滿足了涉眾使用系統(tǒng)的場景之后，該系統(tǒng)就是一個成功的系統(tǒng),。

建立用例

用例定義：工具—>過程—>操作數(shù) （主 謂 賓）

• 參與者：某些具有行為的事物,，可以是人，計算機(jī)系統(tǒng)或組織
• 場景：參與者和系統(tǒng)之間的一系列特定的活動和交互

• 用例：一組相關(guān)的成功和失敗的場景集合,，用來描述參與者如何使用系統(tǒng)來實現(xiàn)目標(biāo)

用例規(guī)范

用例其實就是對一件獨(dú)立事情的描述,，這非常符合我們?nèi)祟愓Z言的表達(dá)過程，我們?nèi)粘贤ê艽蟛糠质顷愂鲆粋€觀點,，那就是以主謂賓的方式來表達(dá),，同樣的編寫用例也可以遵循這個結(jié)構(gòu)。

建模過程

• 用例模型

用例：每個用例提供了一個或多個場景,，該場景說明了系統(tǒng)是如何和最終用戶或其它系統(tǒng)互動,，也就是誰可以用系統(tǒng)做什么，從而獲得一個明確的業(yè)務(wù)目標(biāo),。編寫用例時要避免使用技術(shù)術(shù)語,，而應(yīng)該用最終用戶或者領(lǐng)域?qū)＜业恼Z言。

用例模型：用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型,，它可以作為客戶和開發(fā)人員之間的契約,。用例是貫穿整個系統(tǒng)開發(fā)的一條主線。同一個用例模型即為需求工作流程的結(jié)果,，可當(dāng)作分析設(shè)計工作流程以及測試工作流程的輸入使用,。

用例有嚴(yán)格的規(guī)范，回顧上文系統(tǒng)分析里面,，我們對系統(tǒng)功能分析給出一個公式：

功能 = 主體 + 操作 + 操作對象

那么用例也是需要這樣的結(jié)構(gòu),，比如“我愛你”是完整的用例，能完整的描述一件事情,，而“愛你”則不能稱為一個用例,。所以用例模型建立階段就要力求把用戶訴求都完整的以用例表達(dá)出來。

• 業(yè)務(wù)模型

業(yè)務(wù)模型：業(yè)務(wù)模型采用業(yè)務(wù)用例來繪制,，表達(dá)業(yè)務(wù)的觀點,。

我們在數(shù)據(jù)平臺對用例模型進(jìn)行抽象。

分析師 為 客戶  制作  業(yè)務(wù) 報表

抽象起來就是分析師制作報表,，這個是我們最樸素的模型,，我們以這個最原始最核心的用例為立足點點開始發(fā)散,。

賓語：報表

經(jīng)過我們對語言的分析，已經(jīng)很清晰的呈現(xiàn)出我們的業(yè)務(wù)模型,，就是分析師制作報表,，加上狀語和定語的修飾，我們知道是為客戶這個主體創(chuàng)建的報表,，而且是特定領(lǐng)域的報表,，狀語就是跟分析師強(qiáng)相關(guān)的。

• 概念模型

概念模型：概念模型是一種或多或少的形式化描述,，描述的內(nèi)容包括建立軟件組件時,，所用到的算法、架構(gòu),、假設(shè)與底層約束,。這通常是對實際的簡化描述,，包括一定程度的抽象,，顯式或隱式地按照頭腦中的確切使用方式進(jìn)行構(gòu)建。

現(xiàn)在我們明確了業(yè)務(wù)模型后,，接著就是細(xì)化用戶,，補(bǔ)充更多的細(xì)節(jié)：

分析師 為 不同的客戶  制作  不同業(yè)務(wù)的 報表

分析師 為 不同的客戶  制作  幾款業(yè)務(wù)的 報表

分析師 為 不同的客戶  制作  一項業(yè)務(wù)不同區(qū)域的 報表

兩個分析師 為 某個群體用戶  制作  業(yè)務(wù)線的 報表

客戶 授權(quán) 某個群體  查看  不同業(yè)務(wù)的 報表

結(jié)合我們對業(yè)務(wù)的了解，可以豐富領(lǐng)域的屬性,，還有一個隱性的“權(quán)限”名詞,，我們需要獨(dú)立出來，因為權(quán)限不屬于任何一個領(lǐng)域,。

通常我們需要角色概念來管理用戶訪問報表的權(quán)限

管理員 為 不同的客戶  創(chuàng)建  一項業(yè)務(wù)不同區(qū)域的 角色

管理員 為 不同的客戶  分配  一項業(yè)務(wù)不同區(qū)域的 角色

小二 為不同報表  創(chuàng)建  不同  權(quán)限

• 系統(tǒng)模型

系統(tǒng)模型：系統(tǒng)模型是一個系統(tǒng)某一方面本質(zhì)屬性的描述,，它以某種確定的形式（如文字、符號,、圖表,、實物、數(shù)學(xué)公式等）提供關(guān)于該系統(tǒng)的知識,。

豐富業(yè)務(wù)場景后,，整體的用例如下圖：

分析師 為 不同的客戶  制作  不同業(yè)務(wù)的 報表

工程師 為制作 個性  報表

小二 給不同業(yè)務(wù)創(chuàng)建報表模板 來生成報表

小二創(chuàng)建權(quán)限 來 匹配報表

客戶創(chuàng)建角色

客戶分配角色

客戶篩選人群進(jìn)行營銷活動

前置條件：業(yè)務(wù)告警？

未來一年業(yè)務(wù)場景下的用例如下：

領(lǐng)域驅(qū)動

用例驅(qū)動的一種從局部到全體的思維方式,，剛剛接觸某一行業(yè)的人員從零開始來了解業(yè)務(wù),，復(fù)雜業(yè)務(wù)很難一開始就擁有上帝視角來分析業(yè)務(wù)。而領(lǐng)域驅(qū)動則是一開始就站在上帝視角來著手業(yè)務(wù),，領(lǐng)域驅(qū)動要求化整為零,，它是一種由內(nèi)而外，先內(nèi)功后招式的思想,。它要求團(tuán)隊里有資深的業(yè)務(wù)領(lǐng)域?qū)＜?，該專家對業(yè)務(wù)領(lǐng)域極其了解,，不但要了解其然，還要理解其所以然,，或者是能夠跟領(lǐng)域?qū)I(yè)人員學(xué)習(xí)到足夠的領(lǐng)域知識,。在此條件下，團(tuán)隊將從業(yè)務(wù)領(lǐng)域里找出反映業(yè)務(wù)本質(zhì)的那些事物,、規(guī)則和結(jié)構(gòu),，把它抽象化，描述業(yè)務(wù)運(yùn)行的基本原理和業(yè)務(wù)交互的機(jī)制,，識別出用戶的首要利益,。領(lǐng)域驅(qū)動需要領(lǐng)域?qū)＜疑疃葏⑴c，訪談專家,，才肯跟得出領(lǐng)域模型,，單靠技術(shù)人員本身很難得出完成得領(lǐng)域模型。語言就是承載思想或者想法的模型,，不同的語言建模出不同的思想,，中西語言差異早就思維差異，所以需要領(lǐng)域模型需要從語言談起,，語言描述的事物,，由于領(lǐng)域模型本質(zhì)上傳遞的是概念，是知識性的信息,，語言正是讓知識傳遞成為可能,。對于軟件開發(fā)的場景來說，把這些知識顯式化,，能快速對齊不同角色,、不同參與方之間的概念，加速溝通,，避免誤解,。

領(lǐng)域模型

我們先得搞清楚領(lǐng)域模型的概念，然后才有領(lǐng)域驅(qū)動,。

領(lǐng)域模型是采用業(yè)務(wù)對象建立起來的一種模型,，我們把領(lǐng)域模型當(dāng)中使用到的業(yè)務(wù)對象稱為領(lǐng)域類。

回顧我們學(xué)了很多年的面向?qū)ο笞兂稍O(shè)計,，而實際上真正使用面向?qū)ο箝_發(fā)的思維卻是比較稀少的,，比如傳統(tǒng)MVC架構(gòu)下的web開發(fā)，基本是失血模型的對象,，讓我們很少真正使用面向?qū)ο髞韺崿F(xiàn)我們的業(yè)務(wù),。而真是由于缺少面向?qū)ο蟮臉I(yè)務(wù)實現(xiàn)的必要訓(xùn)練，讓很人使用領(lǐng)域驅(qū)動時覺得困難重重,，這就需要我們對領(lǐng)域模型有一些基本的認(rèn)識,，然后在訓(xùn)練中來深化對領(lǐng)域模型,，面向?qū)ο蟮恼J(rèn)識。

領(lǐng)域模型的核心思想是對象,，而領(lǐng)域驅(qū)動的核心是分層,，需要對實現(xiàn)架構(gòu)進(jìn)行分層，不同的團(tuán)隊,，不同業(yè)務(wù)可能會有相應(yīng)不同的分層,，但是整體上分層的思想就是解耦，把復(fù)雜的事情分解開來簡單化處理,。

傳統(tǒng)架構(gòu)掛著面向?qū)ο蟮拿?，實際上干的全是面向過程的勾當(dāng)，用戶界面,，數(shù)據(jù)庫操作以及其他輔助性代碼進(jìn)程被寫到業(yè)務(wù)對象里面,，原因就是能讓業(yè)務(wù)快速的跑起來，而領(lǐng)域驅(qū)動則打破了這個傳統(tǒng),，給出了通用的架構(gòu)解決方案,，包含4個概念層：

將應(yīng)用按層分離并且建立好約束的交互規(guī)則是很有必要的，代碼如果沒有被放在正確的位置上,，則很快會發(fā)生混亂,。領(lǐng)域?qū)幼詈诵牡穆氊?zé)只應(yīng)該關(guān)心領(lǐng)域方面的業(yè)務(wù)問題,?；A(chǔ)設(shè)施則只需關(guān)心底層的數(shù)據(jù)交互和外界的數(shù)據(jù)通訊交換，而無需關(guān)注業(yè)務(wù)的實現(xiàn),。代碼層面上各層的實現(xiàn)職責(zé)如下：

• 接口層：該層包含與其他系統(tǒng)進(jìn)行交互的接口與通信設(shè)施,，在多數(shù)應(yīng)用里，該層可能提供包括Web Services,、RMI或Rest等在內(nèi)的一種或多種通信接口,。該層主要由Facade、DTO和Assembler三類組件構(gòu)成,。

• 應(yīng)用層：Application層包含的組件就是Service,在領(lǐng)域驅(qū)動設(shè)計的架構(gòu)里,，Service的組織粒度和接口設(shè)計依據(jù)與傳統(tǒng)Transaction Script風(fēng)格的Service是一致的，但是兩者的實現(xiàn)卻有著質(zhì)的區(qū)別,。TransactionScript風(fēng)格的Service是實現(xiàn)業(yè)務(wù)邏輯的主要場所,，因此往往非常厚重。而在領(lǐng)域驅(qū)動設(shè)計的架構(gòu)里,，Application是非?！氨　钡囊粚樱械腟ervice只負(fù)責(zé)協(xié)調(diào)并委派業(yè)務(wù)邏輯給領(lǐng)域?qū)ο筮M(jìn)行處理,，其本身并真正實現(xiàn)業(yè)務(wù)邏輯,，絕大部分的業(yè)務(wù)邏輯都由領(lǐng)域?qū)ο蟪休d和實現(xiàn)了,，這是區(qū)別系統(tǒng)是Transaction Script架構(gòu)還是Domain Model架構(gòu)的重要標(biāo)志。

• 領(lǐng)域?qū)樱篋omain層是整個系統(tǒng)的核心層,，該層維護(hù)一個使用面向?qū)ο蠹夹g(shù)實現(xiàn)的領(lǐng)域模型,，幾乎全部的業(yè)務(wù)邏輯會在該層實現(xiàn)。Domain層包含Entity（實體）,、ValueObject(值對象),、Domain Event（領(lǐng)域事件）和Repository（倉儲）等多種重要的領(lǐng)域組件。

• 基礎(chǔ)設(shè)施層：作為基礎(chǔ)設(shè)施層,，Infrastructure為Interfaces,、Application和Domain三層提供支撐。所有與具體平臺,、框架相關(guān)的實現(xiàn)會在Infrastructure中提供,，避免三層特別是Domain層摻雜進(jìn)這些實現(xiàn)，從而“污染”領(lǐng)域模型,。Infrastructure中最常見的一類設(shè)施是對象持久化的具體實現(xiàn),。

建模過程

有了領(lǐng)域建模的基礎(chǔ)知識后，下面我們介紹下領(lǐng)域建模的過程,。

• 用戶訪談

充分貼合業(yè)務(wù),，基于現(xiàn)有人員資源能力（比如采集到的重要信息是游戲研發(fā)團(tuán)隊中數(shù)據(jù)團(tuán)隊業(yè)界配比大概是不到5%）

痛點：老經(jīng)分?jǐn)?shù)據(jù)報表開發(fā)流程不一致，配置效率低,，排查問題難,，產(chǎn)出報表慢

• 領(lǐng)域知識

首先我們分析項目在領(lǐng)域分層后的概念

項目涉及到的名詞：

分析師，工程師,，客戶,，小二

報表，報表模板,，權(quán)限,，角色，告警,，人群,，活動，決策

動詞：登陸,，創(chuàng)建權(quán)限,，匹配權(quán)限，授權(quán),，建表,，圈人，營銷

實體：報表，報表模板,，權(quán)限,，角色，人群,，活動,，決策

值對象：告警

服務(wù)：登陸，創(chuàng)建權(quán)限,，報表匹配權(quán)限,，授權(quán)給用戶，創(chuàng)建報表,，圈人,，營銷

模塊：報表域，權(quán)限域,，洞察域,，營銷域

聚合根：報表（報表模板，報表數(shù)據(jù)）,，權(quán)限（權(quán)限,，角色），活動（人群,，營銷規(guī)則）

工廠：報表模板工廠,，人群工廠，決策工廠,，權(quán)限工廠

資源庫：數(shù)據(jù)庫,，消息，外部接口

• 領(lǐng)域模型

經(jīng)過對領(lǐng)域知識的消化,，就可以輸出領(lǐng)域模型圖

經(jīng)過了漫長的前戲--模型建立,，本篇終于到了架構(gòu)設(shè)計了,，真的不容易啊,。一開始我總是在糾結(jié)架構(gòu)師應(yīng)該輸出什么架構(gòu)圖，什么才是標(biāo)準(zhǔn)的架構(gòu)圖,，但是當(dāng)我理解什么是架構(gòu),，架構(gòu)形成的過程后，我不在糾結(jié)了,，架構(gòu)存在每一個階段,，以不同的形態(tài)出現(xiàn)，業(yè)務(wù),，產(chǎn)品,，技術(shù)，實施不同的階段都需要一張?zhí)峋V挈領(lǐng)的架構(gòu)圖來指導(dǎo)系統(tǒng)建設(shè)。系統(tǒng)架構(gòu)這個詞經(jīng)常放在一起說,，以至于我們覺得天經(jīng)地義,，經(jīng)常混為一談,。系統(tǒng)指的是由一堆實體組成的一個具備某些功能的整體,，而架構(gòu)則是架和構(gòu)也即是框架和結(jié)構(gòu)，也就是具備穩(wěn)定訴求而且是可以支撐整體的組件,。系統(tǒng)可以沒有架構(gòu),，比如我們亂糟糟的系統(tǒng)。但是系統(tǒng)同時也是需要架構(gòu)的,，架構(gòu)就像是系統(tǒng)的DNA,，架構(gòu)覺得了系統(tǒng)的走向和生命周期，好的架構(gòu)可以支撐系統(tǒng)持久的運(yùn)行和更新迭代,。

架構(gòu)定義

我們先來對架構(gòu)進(jìn)行定義：

架構(gòu)：對系統(tǒng)中實體與實體之間的關(guān)系進(jìn)行抽象的描述,，用于指導(dǎo)軟件系統(tǒng)各個方面的設(shè)計。

架構(gòu)分類

隨著互聯(lián)的發(fā)展,，應(yīng)用從單體到分布式,，到如今基礎(chǔ)設(shè)施的變革，我們迎接云原生時代,，系統(tǒng)的架構(gòu)隨著基礎(chǔ)技術(shù)的突破也不斷的演化,，單體應(yīng)用最簡單最常見的架構(gòu)就是分層架構(gòu)，比如我么熟悉的MVC架構(gòu),，由于業(yè)務(wù)發(fā)展到一定層度后,，需要對服務(wù)進(jìn)行解耦，進(jìn)而把一個單一的大系統(tǒng)按邏輯拆分成不同的子系統(tǒng),，通過服務(wù)接口來通訊,，面向服務(wù)的設(shè)計模式，最終需要總線集成服務(wù),，而且大部分時候還共享數(shù)據(jù)庫,，出現(xiàn)單點故障的時候會導(dǎo)致總線層面的故障，更進(jìn)一步可能會把數(shù)據(jù)庫拖垮,，所以才有了更加獨(dú)立的設(shè)計方案的出現(xiàn),。隨著分布式技術(shù)的成熟，微服務(wù)架構(gòu)開始大行其道,，在此基礎(chǔ)上的邊車服務(wù)和servicemesh也開始進(jìn)入蓬勃的發(fā)展,，整體上架構(gòu)有如下分類

• 分層架構(gòu)：MCV，六邊形架構(gòu),，洋蔥架構(gòu)
• 事件驅(qū)動架構(gòu)
• 微核架構(gòu)
• 微服務(wù)架構(gòu)

• 云原生架構(gòu)

推導(dǎo)架構(gòu)

先問題,，后定位，也即是先使命后愿景，解決什么問題,？先定義問題,，何為問題，有矛盾即存在問題,，專業(yè)的抽象和架構(gòu)知識,，以及背后的歸納和演繹的邏輯思考方法，加上豐富的業(yè)務(wù)用例,，通過邏輯排列,，形成業(yè)務(wù)架構(gòu)，首先我們會用以下的表格來描述問題,。

• 演繹

• 將用例進(jìn)行抽象分類成為業(yè)務(wù)模型

• 將業(yè)務(wù)模型進(jìn)行IT層面的思考,，增加非功能性的組件形成系統(tǒng)模型

• 歸納

• 將用例以及問題進(jìn)行分類聚合
• 業(yè)務(wù)用例形成系統(tǒng)架構(gòu)過程需要進(jìn)行歸納

• 對行為穩(wěn)定性，性能考慮的總結(jié),，歸納為通用組件

架構(gòu)輸出

• 方案概述：對設(shè)計方案的概括性描述
• 設(shè)計約束：包括要遵循的標(biāo)準(zhǔn)或規(guī)范,，技術(shù)上依賴的假設(shè)條件等
• 技術(shù)選型：包括系統(tǒng)運(yùn)行的軟硬件環(huán)境，研發(fā),、測試的軟硬件環(huán)境,，編程語言，現(xiàn)有或開源框架,、平臺,、模塊、基礎(chǔ)庫的重用策略
• 系統(tǒng)結(jié)構(gòu)：包括系統(tǒng)的網(wǎng)絡(luò)部署結(jié)構(gòu),，子系統(tǒng)劃分,。推薦用UML部署圖、包圖描述
• 關(guān)鍵技術(shù)設(shè)計：每個系統(tǒng)關(guān)鍵點不一樣,，但一般都會有安全設(shè)計,，一些算法的設(shè)計
• 接口設(shè)計：包括協(xié)議棧，子系統(tǒng)間的接口數(shù)據(jù)結(jié)構(gòu),，子系統(tǒng)間的業(yè)務(wù)流程描述,。業(yè)務(wù)流程推薦用UML序列圖描述。
• 數(shù)據(jù)設(shè)計：流動的數(shù)據(jù)已通過接口設(shè)計,，這里描述要存儲的數(shù)據(jù),。數(shù)據(jù)的組織形式不一樣，比如NoSQL,，NewSQL，SQL等不同類型,，描述方式也會不一樣,。關(guān)系數(shù)據(jù)庫推薦用ER模型描述頂層邏輯結(jié)構(gòu)，字段表描述物理結(jié)構(gòu)。

• 質(zhì)量預(yù)測：對遺留缺陷率,、平均無故障運(yùn)行時間等質(zhì)量指標(biāo)進(jìn)行預(yù)測,，提出可能出現(xiàn)的缺陷和問題。

總體架構(gòu)輸出如下：

架構(gòu)總結(jié)

• 自底向上：由點及面,，步步為營,，通過用例堆積，分類,，歸納,，劃分，內(nèi)聚,，逐步擴(kuò)大范圍,，再通過剝離，復(fù)用,，從業(yè)務(wù)架構(gòu)到技術(shù)架構(gòu),。

• 自頂向下：洞察客戶背后的本質(zhì)需求，定義問題,，分析問題,，問題分類，優(yōu)先級,，升層思考,，一上來自帶上帝視角。

實際應(yīng)用,，兩者結(jié)合,。

建立用例后，由于對用例分析的方法差異可能生成不同的領(lǐng)域模型,。

模型約束

推導(dǎo)出模型過程中,，需要參考業(yè)界沉淀出來的經(jīng)驗，比如sold原則,，開閉原則等

GRASP設(shè)計原則（職責(zé)分配原則）

信息專家原則(information)

創(chuàng)造者原則(creator)

低耦合原則(low coupling)

高內(nèi)聚原則(high cohesion)

控制器原則(controller)

多態(tài)原則(polymorphism)

純虛構(gòu)(pure Fabrication)

中介原則(indirect)

受保護(hù)變量原則(protected Variations)

設(shè)計原則

GRASP原則,，設(shè)計原則有很多，我們進(jìn)行架構(gòu)設(shè)計的主導(dǎo)原則是OCP（開閉原則）,，在類和代碼的層級上有：SRP（單一職責(zé)原則）,、LSP（里氏替換原則）、ISP（接口隔離原則）,、DIP（依賴反轉(zhuǎn)原則）,；在組件的層級上有：REP（復(fù)用、發(fā)布等同原則）,、CCP（共同閉包原則）,、CRP（共同復(fù)用原則）,，處理組件依賴問題的三原則：無依賴環(huán)原則、穩(wěn)定依賴原則,、穩(wěn)定抽象原則,。這些原則是前人大量的經(jīng)驗總結(jié)，比如設(shè)計模式的原則,，SOLID是幾個重要編碼原則的縮寫：

• 開閉原則（Open Close Principle）開閉原則就是說對擴(kuò)展開放,，對修改關(guān)閉。在程序需要進(jìn)行拓展的時候,，不能去修改原有的代碼,，實現(xiàn)一個熱插拔的效果。

• 里氏代換原則（Liskov Substitution Principle）里氏代換原則(Liskov Substitution Principle LSP)面向?qū)ο笤O(shè)計的基本原則之一,。

• 依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）這個是開閉原則的基礎(chǔ),，具體內(nèi)容：真對接口編程，依賴于抽象而不依賴于具體,。

• 接口隔離原則（Interface Segregation Principle）這個原則的意思是：使用多個隔離的接口,，比使用單個接口要好。還是一個降低類之間的耦合度的意思,，從這兒我們看出,，其實設(shè)計模式就是一個軟件的設(shè)計思想，從大型軟件架構(gòu)出發(fā),，為了升級和維護(hù)方便,。所以上文中多次出現(xiàn)：降低依賴，降低耦合,。

• 迪米特法則（最少知道原則）（Demeter Principle）為什么叫最少知道原則,，就是說：一個實體應(yīng)當(dāng)盡量少的與其他實體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對獨(dú)立,。

• 合成復(fù)用原則（Composite Reuse Principle）原則是盡量使用合成/聚合的方式,，而不是使用繼承。

設(shè)計模式

在編碼過程中,，前人抽象出來的23個設(shè)計模式也是很值得參考的：

創(chuàng)建型模式

• 簡單工廠模式（Simple Factory）
• 工廠方法模式（Factory Method）
• 抽象工廠模式（Abstract Factory）
• 創(chuàng)建者模式（Builder）
• 原型模式（Prototype）

• 單例模式（Singleton）

結(jié)構(gòu)型模式

• 外觀模式（Facade）
• 適配器模式（Adapter）
• 代理模式（Proxy）
• 裝飾模式（Decorator）
• 橋模式（Bridge）
• 組合模式（Composite）

• 享元模式（Flyweight）

行為型模式

• 模板方法模式（Template Method）

• 觀察者模式（Observer）

• 狀態(tài)模式（State）

• 策略模式（Strategy）

• 職責(zé)鏈模式（Chain of Responsibility）

• 命令模式（Command）

• 訪問者模式（Visitor）

• 調(diào)停者模式（Mediator）

• 備忘錄模式（Memento）

• 迭代器模式（Iterator）

• 解釋器模式（Interpreter）

說了這么多，架構(gòu)如何落地的,，相信這個是大家最關(guān)心的,，前文我們已經(jīng)從整體上建立了系統(tǒng)設(shè)計的方法論，在從it領(lǐng)域上升到通用商務(wù)領(lǐng)域的設(shè)計思維,，在系統(tǒng)設(shè)計的層面又步步為營給出了工具和剖析模型建立架構(gòu)推導(dǎo)的一步流程,。其實到了這一步，架構(gòu)設(shè)計已經(jīng)到了柳暗花明的階段了,，因為我們已經(jīng)已經(jīng)把最核心的環(huán)節(jié)都弄通了,，接下來無非對癥下藥,，根據(jù)需求找到系統(tǒng)薄弱的地方,，相應(yīng)的使用適用的工具來發(fā)揮最大的作用,。

行業(yè)架構(gòu)

目前大部分行業(yè)其實都已經(jīng)有相對穩(wěn)定成熟的應(yīng)用架構(gòu)，也形成了基本的套路,，比如金融行業(yè)有傳統(tǒng)的基于IOE的商業(yè)應(yīng)用架構(gòu),，也有新型互聯(lián)網(wǎng)的去IOE基礎(chǔ)上的架構(gòu)，比如微服務(wù)化的流行,，在即時通信的消息架構(gòu)也是有成熟的解決方案,。另外產(chǎn)業(yè)互聯(lián)網(wǎng)各個傳統(tǒng)行業(yè)的互聯(lián)網(wǎng)化也可以應(yīng)用邊緣計算架構(gòu)來實現(xiàn)。

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

行業(yè)下沉到技術(shù)架構(gòu)層面,，從小微企業(yè)到大型企業(yè)應(yīng)用的解決方案,，都逃不過，網(wǎng)關(guān)設(shè)計,，流量管理,，服務(wù)治理，容錯設(shè)計,，監(jiān)控告警,，性能調(diào)優(yōu)，數(shù)據(jù)管理等環(huán)節(jié),，而這方面的設(shè)計實現(xiàn)業(yè)界也提供了成熟的開源解決方案,，可以參考《分布式設(shè)計知識體系》一文，除了巨型企業(yè)需要自研外,，多數(shù)開源的工具已經(jīng)可以滿足大部分需求,，那么架構(gòu)設(shè)計其實就是選擇最適當(dāng)?shù)墓ぞ邅斫鉀Q我們的問題。

系統(tǒng)設(shè)計猶如醫(yī)生看病需要對癥下藥,，醫(yī)生需要博學(xué)多才精通藥理，才能對癥下藥,，就像架構(gòu)師經(jīng)驗豐富,，懂得各種軟件工具（藥）的利弊，各種設(shè)計原則和設(shè)計理論（藥理）可以設(shè)計出架構(gòu)圖（藥方）,，把軟件工具精妙的組合在一起,。學(xué)習(xí)的最佳方式是先進(jìn)行比喻，其次是模仿,，最后回歸到概念的本質(zhì)定義,。一個好的軟件架構(gòu)師，同樣可能成為很好的hr專家,。本文分為三個部分從思維講起到系統(tǒng)逆向分析,，到后面的正向設(shè)計,。從“道，理,，術(shù)”三個角度詮釋了系統(tǒng)架構(gòu)設(shè)計的全面知識體系,。

最后例行給出腦圖：