一文詳解架構設計的本質

阿里妹導讀

本文分為三個部分，從思維講起到系統逆向分析，到後面的正向設計。從“道，理，術”三個角度詮釋了系統架構設計的全面知識體系。

一、問題

1、什麼是系統設計，系統設計的核心是什麼？

2、如何訓練系統設計的思維模式？

3、有什麼方法來幫助我們理解複雜的系統？

4、如何進行系統分析？

5、架構設計的本質是什麼？

6、如何進行架構設計？

7、如何進行業務領域建模？

8、模型如何推匯出架構設計？

9、架構設計需要遵循哪些規範？

二、關鍵詞

系統思維，系統分析，系統設計，架構元素，架構檢視，架構模型，業務模型，概念模型，系統模型，分析模型，設計模型，用例驅動，領域驅動，物件，功能，物件結構，功能互動，利益，架構工具，決策選擇，架構師，架構圖。

三、全文概要

軟體從業人員的成長路線大體是在管理線和技術線上形成突破，當然也有結合起來相得益彰的。而技術上的追求，架構師則是一個重要的門檻，對於剛入行的程式設計師可能會認為架構師就是畫架構圖的，誠然架構師很重要的一個職責是繪製架構圖，但這只是其中一個很小的環節而已。而實際上架構也只是系統設計裡面的一個重要環節，除了架構還包含了商業訴求，業務建模，系統分析，系統設計等重要領域。本文嘗試從更高視角重新審視架構設計的工作，把架構設計的上升到系統設計的立體空間去探索，最終勾勒出系統設計的全域知識體系。

四、思維分析

4.1系統總覽

人類社會活動中的不管大大小小的，簡單抑或複雜的事物，總要先出現在我們的腦海裡，然後再投射到現實的物理空間來。我們總是在孜孜不倦地追求美好的事物，但現實存在的問題就是，首先我們的腦袋也理解不了太過複雜的東西，其次腦海裡的想象有時候也很難真實無損的對映成現實的系統，再者由於總是資源有限的，我們並沒有花不完的預算。歸結起來設計一個系統，或者樸素的說，做一件事情，我們需要解決以下的問題：

在解決以上提出的問題前，首先宣告我們要實現的是一個系統，而不是隨意混搭的一件物品，畢竟現在討論的不是行為藝術。那麼就需要先來了解系統的定義:

系統是由一組實體和實體之間關係構成的集合，其功能大於各個實體功能之和。

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

自然系統：

人體系統
生態系統
大氣系統
水源系統

人工系統：

機械系統
電子系統
作業系統
社會系統

4.2系統演化

上面談到在系統設計流程主要是使用了分析思維和系統思維的結合，當然人類思維還有其他的運作模式，比如批判思維，創新思維和發散思維等，以此衍生的又是另外一套截然不同的方法論。下面我們主要分析系統設計過程中的思維活動。通常談起架構師就會聯想到各式各樣的架構圖，談架構圖就要搞清楚什麼是架構設計，那麼架構設計之前是什麼呢？架構設計是整個系統建設的核心環節，猶如設計圖紙之於建築那麼重要，那架構設計之上應該就是系統設計了。先搞清楚系統設計的定義：

系統設計是根據系統分析的結果，運用系統科學的思想和方法，設計出能最大限度滿足所要求的目標系統的過程。

業務描述

上節弄清楚系統的概念，也就是先把邊界框定下來，那麼我們要實現的無非就是以上類別的系統。自然系統是天然形成的，或者你願意的話也可以認為是盤古開天闢地形成的，那也可以歸為人為系統。我這麼說的原因是嘗試把視角從軟體這個領域往更加宏觀的方向提升，讓我們暫時忘掉軟體架構師這一根深蒂固的角色。

假設現在我們想登上火星，言下之意是需要藉助一套裝置要把人類送到火星上，大膽一點，發揮僅存那點為數不多的物理知識儲備，要設計出一套系統，能夠把人類送到火星。這個時候老闆就是願意出資去火星豪華7日遊的金主，那麼需要一個負責人來實現這趟旅程，我們姑且把這個負責人就稱為登火旅行系統架構師（叫總設計師也行，不需要在意這種細節）。那麼這個系統架構師的工作，就是把登陸火星的一系列需求和目標轉化成為足於支撐登陸火星龐大工程的系統架構。

根據系統總覽提到的問題，先一一作答。

維度	問題	方案
性質	這件事是否合法合規？	必須確認旅客人身安全
受眾	這件事情最終誰是受益方？	主體是金主，參加系統建設的供應商
利益	這件事做完能帶來什麼收益？	美好的旅行回憶，提升人類航天水平
目標	要做一件什麼樣的事情？	火星旅行，把人安全送到火星再安全送回來
需求	怎樣把這件事合理的列舉出來？	人身安全住的舒服吃的美味少花點錢旅程快點最好下次能大幅減少成本全程跟拍帶回紀念品
抽象	怎樣把這件事的主線說明清楚？	輸出業務架構/概念架構/系統架構
設計	選擇什麼工具把這件事實現出來？	技術選型組合
方向	這件事是否違背了我們的初衷	不斷驗證測試

由於人命關天，這項工作看起來是挺複雜的，初次接到這個單子時我內心是彷徨的。但是回答了以上問題後，感覺明朗了不少，我們在完成系統性質，受眾，利益和目標的分析和解答後，才能進入到系統的架構階段。首先對以上提到的需求，我們先用動畫片裡面的簡單畫面為基礎來描繪我們的設計，然後大致根據能想到的過程完成初次業務流程的描述。

業務流程畫圖元素：火箭，機艙，地球，火星，來回，基礎功能（安全，舒適，成本）

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

概念抽象

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

概念是抽象的、普遍的想法，是充當指明實體、事件或關係的範疇或類的實體。

簡單來說，概念就是用簡單的一個詞彙，就可以讓在座的大家都能準確無誤的理解這個詞彙所表達的含義。這個是語言獨特的魅力，可以說有個概念這個武器，才有了人類多次工業革命的文明大爆發。有了“概念”這個工具，再對概念進行組合，會爆發出無窮的生產力。

這裡穿插講一下概念的應用，比“傅立葉級數”這個概念，我敢打賭有80%的人不知道所謂何物，但是沒關係，我們並不是要來科普這個概念，先根據百度百科來看看這個概念的描述：

若在整個數軸上:

且等式右邊級數一致收斂，則有如下關係式:

一般地說，若是以為週期且在上可積的函式，則按上式計算出的稱為函式(關於三角函式系)的傅立葉係數，以的傅立葉係數為係數的三角級數稱為(關於三角函式系)的傅立葉級數，記作：

其中，記號“”表示上式右邊是左邊函式的傅立葉級數

先不要怕，我這麼說的目的不是為了讓大家搞懂什麼是傅立葉級數，這裡我們可以看出即使這麼鬼畜概念也是很普通的基礎概念元素組成的，比如收斂公式，比如三角函式，比如Σ求和概念，甚至像1，2，3這些阿拉伯數字。這裡不得不說學數學最核心的環節就是深刻理解概念，沒有之一。說回來，這裡的語境就是在大家都共同理解接受這些基礎概念後，經過一系列複雜組合的高階概念，也依然能夠清晰嚴謹的表達出來，下面傅立葉級數的產生過程的動圖看看就好。

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

在業務建模後就是概念建模，作為架構設計的輸入，這個階段就需要對核心業務的充分理解，同時在基礎性和通用性方面的功能也需要同時考慮，這個階段需要大量的業務專家和各個領域的科學家通力協作，保證對系統的理解沒有偏差。經過一系列的概念抽象和組合，最終輸出登陸火星工程的架構圖，這裡只是用於說明登陸火星專案同樣遵循這業務-概念-架構-設計的流程，不要在意架構圖本身合不合理。

系統落地

當然這還遠遠不夠，系統之所以複雜，就是我們對系統總有無數更多的要求，更多的功能，更好的效能，那麼接下來就是對各個模組進行分析，細化，設計和實施。當然我們不會班門弄斧真的在這裡去分析登陸火星的實際流程，以上這個例子雖然比較粗曠，但是基本也描繪了一個複雜系統建設的過程，也就是從需求，建模到架構的思維過程，是從最原始的登火需求一步步擴充套件的過程。其實我們還可以舉個小一點的案例，比如一個有趣的需求“賺錢”，引申出來就是做一個能盈利商業專案架構，的有興趣的同學可以根據這個思維模式一步一步勾畫出整個流程出來，相信對這是也不錯的方法，也許還真能解決些許困惑。下面演示的就是登月過程宏觀層面落地的步驟。

4.3架構思維

架構目標

一直以來我聽過很多人在講架構，有些人在做架構，但是很難討論出一個大家都滿意的定義，什麼是架構師，架構師需要做哪些工作？或者說很少有往深的去思考，只知道被稱為架構師說明這個人很厲害。在我畢業的時候有個同學打趣的跟我說，你們做程式的無非就是增刪改查，當時我竟無言以對，當時腦海裡浮現的是一系列工具的應用技巧，比如tomcat，nginx的使用，還有對業務的翻譯。隨著對業務的貼近和對計算機技術的進一步認識，我重新審視“這世上的系統無非就是增刪改查”，這句話說對也對也不對，這句話就跟計算機軟體無非就是0和1的集合，也對也不對。特別是對剛入行的人可能覺得設計離自己比較遠，因為習慣了開啟idea才開始考慮業務，寫程式碼才開始思考領域模型，這是非常不好的習慣，好像如果沒有在coding狀態下是無法進行建模思考，這個很難，需要持久的訓練才能達成設計階段進行思考。架構設計只是系統設計裡面的一個階段，而系統設計是應用建設裡面的核心環節，有一些簡單的應用建設是不需要系統設計的，當然有一些複雜的應用，在能力超強的工程師團隊，有足夠的默契後，也可以直接進行建設。

軟體架構之道最核心的問題是解決複雜性的問題，並且在解決問題的過程中找到最佳的平衡點，既要簡單又能滿足發展。描述系統設計的本質，就是實現縱向上的時間，橫向上的空間進行考慮，規劃出決策路徑，最終拿到目標結果。架構師眼裡第一件事不是多流行的技術，多高效能的框架，或者多完善的業務模型，而應該聚焦在利益之上。對，這個可能會顛覆一些認知，當我們真正把利益放在首位後，再去考慮接下來要完成的事情，我們的工作才能稱得上架構。也就是說，架構師的天職就是最大限度的實現客戶的利益，這裡的客戶可以是市場客戶，也可以是協作團隊，還可以是同一個團隊的專案成員。再直白的說，架構師就是負責把老闆畫的餅給實現了，在相當長的一段時間內保證產物有足夠的利益回報。有人會說那我們做的就是公益專案，就不考慮利益，那我我補充一下，這裡說的利益不止是經濟收益，還有系統帶來的社會價值。那麼又有人會說，架構是追求利益回報，那老闆的目標就是炒股發大財，請架構師你給我選幾支股票吧，那我會說其實優秀的基金經理也可以稱為廣義上的架構師。

架構過程

自然在增熵，而系統架構過程其實就是減熵的過程，一個架構的誕生始於目標的確立，然後對需求的刻畫，繼而是落地方法的抉擇。所謂條條大路通羅馬，有的是一路平川而有的則是崎嶇不平，那麼架構過程就是不斷歸類合併同類項，力求最合適的決策選擇來實現我們所要達成的願望。在面對複雜業務的場景下，我們需要做出如下的思考：

確定系統實體物件和預期功能
抽象系統實體之間的關係，功能與實體的關係
劃定系統的邊界和外部環境的關係
預測系統帶來的效果

在架構過程很重要的一項任務就是識別系統的實體關係和功能關係，進而對系統效果進行預測，也就是在完一系列的分析建模工作後推匯出來的系統架構需要在預測上達到我們要的效果，那麼系統預測通常有如下四種方式：

經驗
實驗
建模
推理

系統思維

系統思維不等於系統化思考，與系統思維並列的可以是批判思維，分析思維，創新思維，而我們追求的是元認知，也即是認識到自己處於何種思維模式。系統思維目標：

理解系統是什麼
預測系統的走向
為決策提供知識支援

系統思維首先是高效的理解分析現存的系統，對系統重構做好理論指導基礎。

這一節介紹了設計一個系統需要經歷哪些重要的環節，並且強調了謀求利益是系統設計的核心訴求。然後透過登陸火星這項任務把一個龐大的工程變成了可理解的獨立步驟，並且還有模有樣的畫出了架構圖，體現了對業務建模到架構輸出的流程。下面章節我們將會展開來介紹一套核心的方法論，如何破局系統架構設計。

五、系統分析

上一節談論了系統設計的心智模型和投射到物理世界的演化規律，但前提是建立在已經具備豐富系統設計經驗基礎上。而在進行系統架構之前，需要先對系統分析有一定的理解，好比我們製造發動機之前，得先把發動機拆下來好好研究一番，直接上來就要設計出發動機有點像空中樓閣。本節講提供一套基礎的方法，來對現有系統進行分析，得出一些系統架構相關的推論。按照慣例需要先搞清楚系統分析的概念：

系統分析，旨在研究特定系統結構中各部分的相互作用，系統的對外介面與介面，以及該系統整體的行為、功能和侷限，從而為系統未來的變遷與有關決策提供參考和依據。系統分析的經常目標之一，在於改善決策過程及系統性能，以期達到系統的整體最優。

大到銀河系，小至原子粒子都有著特有的結構，何謂結構：

結構是指在一個系統或者材料之中，互相關聯的元素的排列、組織關係

而系統在物質世界裡面當然也遵循這樣的規則，分析系統跟分析銀河系也一樣，需要對它的組成元素和元素之間的關係進行分析。而對系統的分解也是講究方法的，可以參考以下總結的一些方向：

體系歸納
層級分解
邏輯關係
自頂向下
自底向上
由外向內
由內而外

5.1實體分析

實體指系統物理時空存在的單元，彼此透過一定的結構形成系統，那麼在分析實體之前，我們可以帶著下面的問題進行分析：

系統是什麼？
構成系統的元素有哪些？
系統元素之間的結構是什麼？
系統的邊界在哪裡？
系統的使用場景是什麼？

實體是系統的一項基礎屬性，是系統的物理體現或資訊體現。對功能的執行起工具性作用，而描述實體通常可以使用以下工具來表達：

文字描述
符號描述
插圖
插畫
示意圖
三維圖
透檢視

實體之間的關係就是結構，分析結構時需要對實體進行分解，實體可以建模為物件以及象之間的結構，進一步可以分解為小的實體，又可以聚合起來稱為系統本身，對實體之間的各種結構分析則可以得出系統架構，即是把功能元素組合成物理塊時所用的編排方式

分析實體

對實體的載體進行抽象聚類，形成物件，體現出邊界
用適當的層次來分解架構的實體

分析關係

也即是實體的結構，是物件之間存在穩定關係，有助於功能互動的執行系統實體有如下關係：

空間拓撲關係
連線性關係
地址關係
順序關係
成員關係
所有權關係
人際關係

5.2功能分析

上面一節我們瞭解了系統的物理基礎，對組成系統的實體進行分解，分析，進而對實體的關係描述為結構，對結構抽象是得出架構的基礎步驟，而系統物理基礎存在的理由是為了實現我們的訴求，也即是系統的功能。畢竟萬物皆有因，存在即合理，系統構建最終也是要達成我們的意願，完成這個訴求才算是合格的架構。分析形式相對來說畢竟簡單，畢竟實體是有形的便於理解，而功能則是由實體組合湧現出來的屬性，功能分析過程需要跟實體不斷的互動穿插。

關於系統功能其實可以樸素的認為就是動賓短語的集合，功能=動詞+賓語，含義就是實體狀態變化的過程，就是功能的體現，具體分析下文會詳細展開。

功能 = 主體 + 操作 + 操作物件，比如嘴巴有“吃飯”功能，飛機有“搭載乘客”功能，報表平臺有“展示報表”功能。

操作：物件經歷的一種轉換模式，過程設計運算元的狀態變化。

操作物件：運算元是一個物件，在某段時間內穩定且無條件存在，運算元不需要先於功能的執行而存在，運算元可能會由功能中的過程部分來建立，修改或消耗。

總結起來，系統分析就是建立一套方法論，去分析複雜的系統，令系統不再那麼難懂。

六、系統設計

經過了上幾節的思維訓練和系統逆向分析，我們也大概理解了系統設計的流程和系統架構的形成過程，本節正向介紹系統設計，包括設計工具，需求分析，模型建立，架構推導，設計規範完整的系統設計流程。系統設計，也即是設計出一套良好的系統架構，就是構建一套具備必要複雜度又不難懂的系統。下面在介紹方法輪的同時，同時會穿插一個數據平臺的大致設計過程。

在進入本章節系統設計前，我們先要來學習學習一個架構TOGAF：

TOGAF：框架開放組體系結構框架（The Open Group Architecture Framework，縮寫：TOGAF）是一個企業架構框架，它提供了一種設計，規劃，實施和管理企業資訊科技架構的方法。TOGAF是一種高層設計方法。它通常被建模為四個級別：業務，應用程式，資料，和技術。

在TOGAF中，任何一種企業能力的建設都需要對如下四種領域進行設計，包括針對這一可持續性架構實踐建設：

業務架構：突出了架構治理、架構流程、架構組織結構、架構資訊需求以及架構產品等方面
資料架構：定義了組織中架構連續體和架構資源庫的結構
應用架構：描述了用於支援此可持續架構實踐的功能和服務
技術架構：描述了架構實踐中用於支援各架構應用和企業連續體的基礎設施需求和部署方式

TOGAF架構框架是一組工具，可用於開發各種不同的架構：

描述了一種用於根據一組構建塊來定義資訊系統的方法
展示構建塊如何組合在一起
包含一組工具
提供共同的詞彙集合
包括推薦標準列表
包括可用於實現構建塊的相容產品列表

企業可以透過應用企業架構開發方法（ADM）來為建設各種業務能力，然後我們再來介紹另外一種系統設計的思路。

6.1設計工具

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

核心元素

參與者
用例
邊界
業務實體
包
分析類
設計類
關係
元件
節點

核心檢視

靜態圖包括：

用例圖
類圖
包圖

動態圖包括：

活動圖
狀態圖
時序圖
協作圖
泳道圖

核心模型

業務用例模型
概念用例模型
系統用例模型
業務領域模型
系統分析模型
系統設計模型
系統元件模型

核心流程

業務建模
系統建模
模型分析
模型實施

軟體工具

draw.io
StarUML
Visual Paradigm

6.2需求分析

本節不打算講需求分析師的工作流程，因為我們已經很熟悉需求分析師對需求的分析過程了，所以無需多言，在講需求之前我們先來看看架構師需要完成的工作。架構師並不是全能的通才，無法面面俱到的瞭解所有細緻的需求，那麼架構師要做的就是簡化系統的複雜度，消除業務歧義，致力於輸出健壯相容的系統架構。由於系統需求分析需要由架構師這個角色全程參與，深度理解業務，下面我們簡單對架構師角色進行討論。

架構角色

我們先看看傳統系統設計兩大核心角色的定義：

系統架構師：是在資訊系統研發中，負責依據需求來確定主要的技術選擇、設計系統的主體框架結構，並負責搭建實施的人。

系統分析師：是在資訊系統研發中，負責透過需求分析確認系統的需求，並進而形成系統產品設計的人。通常他們也會涉及可行性評估、專案管理、開發前評估、需求驗證等工作。

傳統意義的系統開發分為系統架構師和系統分析師兩個角色，但是隨著網際網路的快速發展，如今系統建設越來越趨向兩個角色結合起來，那麼網際網路時代架構師有如下職責：

瞭解問題領域，消除歧義
樹立業務目標，抽象業務用例
完成涉眾分析，發現系統主要受益者
劃清系統邊界，確立對外互動方式
劃分優先級別，聚焦系統核心訴求
分析業務需求，輸出業務模型
抽象業務概念，輸出概念模型
推導系統架構，輸出架構模型
負責技術選型，完成系統落地

架構師是軟體開發活動中的眾多角色之一，它可能是一個人、一個小組，也可能是一個團隊，我們分析的是架構師這個角色，能勝任這個角色的才是架構師，那麼在這個角色上能做得更加出色的就是好的架構師。以上架構師職責是整體上的描述，在細分領域有不同的分類。微軟對架構師有一個分類參考，我們參考一下，他們把架構師分為4種：

企業架構師EA(Enterprise Architect)
基礎結構架構師IA(Infrastructure Architect)
特定技術架構TSA(Technology-Specific Architect)
解決方案架構師SA (Solution Architect)

既然對架構師角色有諸多要求，那麼也可以來歸納一下架構師必備的一些技能，架構師能力要求：

現有資源評估盤點及資源編排能力
消除歧義分清問題主次能力
業務簡化描述，用例抽象思維
通用市場法務市場領域基礎常識
業務分析架構推導能力
計算機基礎理論知識體系
通用技術棧原理認知
工具使用熟練，排查定位問題能力
技術深度廣度
分散式高併發效能調優技能
產品思維

利益分析

首先當然是要確立好客戶，所謂客戶第一，聽起來很簡單，如果只是單一的服務好客戶，那確實不算很難。難的是如果同時存在多個業務方向的客戶，而且客戶直接的利益產生交集，而且存在矛盾，怎麼權衡好利益分配，區分客戶利益優先順序，才是困難的。

不忘初心這一點尤為難得，很多專案做著做著就偏離了當初的目標，這個過程我們一定要緊緊抓住系統最重要的受益者，梳理好系統眾多涉眾的利益分配。

資源評估

資源評估不僅僅是專案經理的事，而是對團隊資源的評估和編排，比如某項業務技術團隊中研發和資料人員的配比，決定了資料平臺投入的資源範圍，這要求架構師在做設計分析的時候需要充分考慮的資源的利用效率，包括人力資源和機器等資源。

需求規範

使用者的訴求體現為需求的輸出過程，不同層次分解需求得出了不同的複雜度，我們知道架構師的一項重要職責就是消除歧義，精準的把握需求來匹配使用者的訴求。那麼就需要一系列規範來保障需求採集的過程中不失真。下面列出了需求採集過程的一些指導原則

每個軟體需求是否都有唯一的識別符號？
每個軟體需求都可以驗證嗎？（如果可能，是否可正規化，量化）
是否對每個軟體要求進行了優先排序？
所有不穩定的軟體要求是否都已標明？
軟體需求是否完整？（涵蓋了所有使用者要求，考慮了所有相關的輸入情況）
軟體要求是否一致？
是否明確指出了軟體需求之間的重疊交叉？
是否明確規定了初始系統狀態？
軟體需求是否表達了邏輯模型，而不是實現形式？
軟體需求是否以結構化的方式表示為抽象層次？
是否足夠清楚，邏輯模型的結構
軟體要求是否已正式形式化？
是否已證明軟體需求的關鍵屬性？
所有形式化的圖表材料是否都隨附了充足解釋性文字？
是否針對專案團隊缺乏經驗的領域描述了探索性原型？

需求描述

在進行需求描述時，我們可以從多個角度來審視需求是否合理的表達出來：

滿足需求，能帶來什麼價值，符合什麼利益訴求
需求無法滿足時，會帶來什麼危害，有何潛在風險
需求是否緊迫，必須在什麼時間段內完成
多個需求直接是否產生耦合，完成一個需求後是否帶來了新的問題
是否能多個備選方案來完成需求

需求採集

回到我們平臺設計的案例上，經過使用者訪談粗略的採集的需求：

• 打破單個遊戲壁壘，實現多個遊戲資料互通，多遊戲，多版本資料融合

• 底層資料生命週期管理，遊戲多服階段管理

• 提升經分一鍵化能力

需求分析：

• 單遊戲壁壘是個困局，本質上是功能缺陷，打通資料壁壘

• 遊戲各個階段目前是物理刪除資料，要多資料底層進行管理

• 現在是配置報表case by case完成的，需要對由相同特性的報表實現一鍵生成

需求背後：

• 可以一次性看更多的資料

• 可以方便的切換資料

• 可以更快的看到資料

所以，這個真的是客戶想要的嗎？整體上，使用者想看什麼資料？同時我也在思考下面的問題：

深入分析使用者需求
搞清楚我們的客戶是誰？
定義好問題，搞清楚問題的本質，分析問題矛盾之處，我們要解決什麼問題？
我們要在多大範圍內去解決問題，要解決跨度多長時間可預計的問題？
我們的邊界在哪裡？
我們的使命是什麼？有了使命後再談我們自己，願景是什麼？

6.3模型建立

在系統設計這個階段，我們已經介紹瞭如何運用工具，還有使用者需求的管理，接下來就是要把需求“消化”成我們需要的架構。但是架構不是平白無故就產生的，前文我們用登陸火星的案例也大概描述了系統的建設過程，那麼在推匯出架構之前，把使用者的不那麼清晰的訴求轉化成嚴謹的業務概念模型就很有必要了。

模型基礎

首先我們要搞清楚模型相關的概念：

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

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

概念模型：是用一組概念來描述一個系統，或用任何代替的形式來描述一個概念，以期能進一步瞭解或說明事物的運作原理。具體的形式可能包括思想實驗、數學模型、電腦模擬、示意圖、比例模型等。

業務建模：是以軟體模型方式描述企業管理和業務所涉及的物件和要素、以及它們的屬性、行為和彼此關係，業務建模強調以體系的方式來理解、設計和構架企業資訊系統。

建模目標

也即是說業務建模是一種建模方法的集合，目的是對業務進行建模。這方面的工作包括了對業務流程建模，對業務組織建模，改進業務流程，領域建模等方面。針對複雜難懂的系統，我們構造出一個比較簡單的模型，來代表複雜的業務，這個是一種有效的辦法，這也是我們需要建模的原因，隨著計算機的飛速發展，或許以後計算機可以幫人類承當一部分的設計工作，而計算機是不怕複雜業務的，也許那個時候就不再需要這種特地適應人類思考的模型了。

建立模型不是最終目的，而是把複雜的業務訴求構建成簡單的業務概念，在軟體開發團隊溝透過程中能形成共識，消除歧義，而且資訊傳遞不失真，為輸出架構奠定基礎。

模型分類

在業務不同的階段，通常會使用不用的模型來表達，一般情況下我們把模型分為：

業務模型
概念模型
系統模型
分析模型
設計模型
物理模型

建模方法

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

領域驅動（DDD）
用例驅動（UDD）
四色建模
CRC建模
CQRS建模

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

用例驅動

用例驅動是一種由外而內，先招式後內功的思想。我們先從涉眾對系統的期望開始，定義出系統如何滿足他們的願望。這一過程是感性的、外在的、符合當前需求的。用例驅動的結果是我們的軟體是以實現一個個場景為目的的，認為當一個系統的行為滿足了所有涉眾的期望之後，即滿足了涉眾使用系統的場景之後，該系統就是一個成功的系統。

建立用例

用例定義：工具—>過程—>運算元（主謂賓）

參與者：某些具有行為的事物，可以是人，計算機系統或組織
場景：參與者和系統之間的一系列特定的活動和互動
用例：一組相關的成功和失敗的場景集合，用來描述參與者如何使用系統來實現目標

用例規範

用例其實就是對一件獨立事情的描述，這非常符合我們人類語言的表達過程，我們日常溝通很大部分是陳述一個觀點，那就是以主謂賓的方式來表達，同樣的編寫用例也可以遵循這個結構。

建模過程

用例模型

用例：每個用例提供了一個或多個場景，該場景說明了系統是如何和終端使用者或其它系統互動，也就是誰可以用系統做什麼，從而獲得一個明確的業務目標。編寫用例時要避免使用技術術語，而應該用終端使用者或者領域專家的語言。

用例模型：用例模型是系統既定功能及系統環境的模型，它可以作為客戶和開發人員之間的契約。用例是貫穿整個系統開發的一條主線。同一個用例模型即為需求工作流程的結果，可當作分析設計工作流程以及測試工作流程的輸入使用。

用例有嚴格的規範，回顧上文系統分析裡面，我們對系統功能分析給出一個公式：

功能 = 主體 + 操作 + 操作物件

那麼用例也是需要這樣的結構，比如“我愛你”是完整的用例，能完整的描述一件事情，而“愛你”則不能稱為一個用例。所以用例模型建立階段就要力求把使用者訴求都完整的以用例表達出來。

業務模型

業務模型：業務模型採用業務用例來繪製，表達業務的觀點。

我們在資料平臺對用例模型進行抽象。

分析師 為客戶製作業務報表

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

主語：分析師

狀語：客戶

謂語：製作

定語：某一項業務

賓語：報表

經過我們對語言的分析，已經很清晰的呈現出我們的業務模型，就是分析師製作報表，加上狀語和定語的修飾，我們知道是為客戶這個主體建立的報表，而且是特定領域的報表，狀語就是跟分析師強相關的。

概念模型

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

現在我們明確了業務模型後，接著就是細化使用者，補充更多的細節：

分析師 為不同的客戶製作不同業務的報表

分析師 為不同的客戶製作幾款業務的報表

分析師 為不同的客戶製作一項業務不同區域的報表

兩個分析師 為某個群體使用者製作業務線的報表

客戶授權 某個群體檢視不同業務的報表

結合我們對業務的瞭解，可以豐富領域的屬性，還有一個隱性的“許可權”名詞，我們需要獨立出來，因為許可權不屬於任何一個領域。

通常我們需要角色概念來管理使用者訪問報表的許可權

管理員 為不同的客戶建立一項業務不同區域的角色

管理員 為不同的客戶分配一項業務不同區域的角色

小二為不同報表建立不同 許可權

系統模型

系統模型：系統模型是一個系統某一方面本質屬性的描述，它以某種確定的形式（如文字、符號、圖表、實物、數學公式等）提供關於該系統的知識。

豐富業務場景後，整體的用例如下圖：

分析師 為不同的客戶製作不同業務的報表

工程師 為製作個性報表

小二給不同業務建立報表模板來生成報表

小二建立許可權來匹配報表

客戶建立角色

客戶分配角色

客戶篩選人群進行營銷活動

前置條件：業務告警？

未來一年業務場景下的用例如下：

領域驅動

用例驅動的一種從區域性到全體的思維方式，剛剛接觸某一行業的人員從零開始來了解業務，複雜業務很難一開始就擁有上帝視角來分析業務。而領域驅動則是一開始就站在上帝視角來著手業務，領域驅動要求化整為零，它是一種由內而外，先內功後招式的思想。它要求團隊裡有資深的業務領域專家，該專家對業務領域極其瞭解，不但要了解其然，還要理解其所以然，或者是能夠跟領域專業人員學習到足夠的領域知識。在此條件下，團隊將從業務領域裡找出反映業務本質的那些事物、規則和結構，把它抽象化，描述業務執行的基本原理和業務互動的機制，識別出使用者的首要利益。領域驅動需要領域專家深度參與，訪談專家，才肯跟得出領域模型，單靠技術人員本身很難得出完成得領域模型。語言就是承載思想或者想法的模型，不同的語言建模出不同的思想，中西語言差異早就思維差異，所以需要領域模型需要從語言談起，語言描述的事物，由於領域模型本質上傳遞的是概念，是知識性的資訊，語言正是讓知識傳遞成為可能。對於軟體開發的場景來說，把這些知識顯式化，能快速對齊不同角色、不同參與方之間的概念，加速溝通，避免誤解。

領域模型

我們先得搞清楚領域模型的概念，然後才有領域驅動。

領域模型是採用業務物件建立起來的一種模型，我們把領域模型當中使用到的業務物件稱為領域類。

回顧我們學了很多年的面向物件變成設計，而實際上真正使用面向物件開發的思維卻是比較稀少的，比如傳統MVC架構下的web開發，基本是失血模型的物件，讓我們很少真正使用面向物件來實現我們的業務。而真是由於缺少面向物件的業務實現的必要訓練，讓很人使用領域驅動時覺得困難重重，這就需要我們對領域模型有一些基本的認識，然後在訓練中來深化對領域模型，面向物件的認識。

領域模型的核心思想是物件，而領域驅動的核心是分層，需要對實現架構進行分層，不同的團隊，不同業務可能會有相應不同的分層，但是整體上分層的思想就是解耦，把複雜的事情分解開來簡單化處理。

傳統架構掛著面向物件的名號，實際上乾的全是面向過程的勾當，使用者介面，資料庫操作以及其他輔助性程式碼程序被寫到業務物件裡面，原因就是能讓業務快速的跑起來，而領域驅動則打破了這個傳統，給出了通用的架構解決方案，包含4個概念層：

將應用按層分離並且建立好約束的互動規則是很有必要的，程式碼如果沒有被放在正確的位置上，則很快會發生混亂。領域層最核心的職責只應該關心領域方面的業務問題。基礎設施則只需關心底層的資料互動和外界的資料通訊交換，而無需關注業務的實現。程式碼層面上各層的實現職責如下：

介面層：該層包含與其他系統進行互動的介面與通訊設施，在多數應用裡，該層可能提供包括Web Services、RMI或Rest等在內的一種或多種通訊介面。該層主要由Facade、DTO和Assembler三類元件構成。
應用層：Application層包含的元件就是Service,在領域驅動設計的架構裡，Service的組織粒度和介面設計依據與傳統Transaction Script風格的Service是一致的，但是兩者的實現卻有著質的區別。TransactionScript風格的Service是實現業務邏輯的主要場所，因此往往非常厚重。而在領域驅動設計的架構裡，Application是非常“薄”的一層，所有的Service只負責協調並委派業務邏輯給領域物件進行處理，其本身並真正實現業務邏輯，絕大部分的業務邏輯都由領域物件承載和實現了，這是區別系統是Transaction Script架構還是Domain Model架構的重要標誌。
領域層：Domain層是整個系統的核心層，該層維護一個使用面向物件技術實現的領域模型，幾乎全部的業務邏輯會在該層實現。Domain層包含Entity（實體）、ValueObject(值物件)、Domain Event（領域事件）和Repository（倉儲）等多種重要的領域元件。
基礎設施層：作為基礎設施層，Infrastructure為Interfaces、Application和Domain三層提供支撐。所有與具體平臺、框架相關的實現會在Infrastructure中提供，避免三層特別是Domain層摻雜進這些實現，從而“汙染”領域模型。Infrastructure中最常見的一類設施是物件持久化的具體實現。

建模過程

有了領域建模的基礎知識後，下面我們介紹下領域建模的過程。

使用者訪談

充分貼合業務，基於現有人員資源能力（比如採集到的重要資訊是遊戲研發團隊中資料團隊業界配比大概是不到5%）

痛點：老經分資料報表開發流程不一致，配置效率低，排查問題難，產出報表慢

領域知識

首先我們分析專案在領域分層後的概念

專案涉及到的名詞：

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

報表，報表模板，許可權，角色，告警，人群，活動，決策

動詞：登陸，建立許可權，匹配許可權，授權，建表，圈人，營銷

實體：報表，報表模板，許可權，角色，人群，活動，決策

值物件：告警

服務：登陸，建立許可權，報表匹配許可權，授權給使用者，建立報表，圈人，營銷

模組：報表域，許可權域，洞察域，營銷域

聚合根：報表（報表模板，報表資料），許可權（許可權，角色），活動（人群，營銷規則）

工廠：報表模板工廠，人群工廠，決策工廠，許可權工廠

資源庫：資料庫，訊息，外部介面

領域模型

經過對領域知識的消化，就可以輸出領域模型圖

6.4架構推導

經過了漫長的前戲–模型建立，本篇終於到了架構設計了，真的不容易啊。一開始我總是在糾結架構師應該輸出什麼架構圖，什麼才是標準的架構圖，但是當我理解什麼是架構，架構形成的過程後，我不在糾結了，架構存在每一個階段，以不同的形態出現，業務，產品，技術，實施不同的階段都需要一張提綱挈領的架構圖來指導系統建設。系統架構這個詞經常放在一起說，以至於我們覺得天經地義，經常混為一談。系統指的是由一堆實體組成的一個具備某些功能的整體，而架構則是架和構也即是框架和結構，也就是具備穩定訴求而且是可以支撐整體的元件。系統可以沒有架構，比如我們亂糟糟的系統。但是系統同時也是需要架構的，架構就像是系統的DNA，架構覺得了系統的走向和生命週期，好的架構可以支撐系統持久的執行和更新迭代。

架構定義

我們先來對架構進行定義：

架構：對系統中實體與實體之間的關係進行抽象的描述，用於指導軟體系統各個方面的設計。

架構分類

隨著互聯的發展，應用從單體到分散式，到如今基礎設施的變革，我們迎接雲原生時代，系統的架構隨著基礎技術的突破也不斷的演化，單體應用最簡單最常見的架構就是分層架構，比如我麼熟悉的MVC架構，由於業務發展到一定層度後，需要對服務進行解耦，進而把一個單一的大系統按邏輯拆分成不同的子系統，透過服務介面來通訊，面向服務的設計模式，最終需要匯流排整合服務，而且大部分時候還共享資料庫，出現單點故障的時候會導致匯流排層面的故障，更進一步可能會把資料庫拖垮，所以才有了更加獨立的設計方案的出現。隨著分散式技術的成熟，微服務架構開始大行其道，在此基礎上的邊車服務和servicemesh也開始進入蓬勃的發展，整體上架構有如下分類

分層架構：MCV，六邊形架構，洋蔥架構
事件驅動架構
微核架構
微服務架構
雲原生架構

推導架構

先問題，後定位，也即是先使命後願景，解決什麼問題？先定義問題，何為問題，有矛盾即存在問題，專業的抽象和架構知識，以及背後的歸納和演繹的邏輯思考方法，加上豐富的業務用例，透過邏輯排列，形成業務架構，首先我們會用以下的表格來描述問題。

主要問題	次要問題	緊急問題	不緊急的問題
第一階段
第二階段
第三階段
第四階段

演繹

將用例進行抽象分類成為業務模型
將業務模型進行IT層面的思考，增加非功能性的元件形成系統模型

歸納

將用例以及問題進行分類聚合
業務用例形成系統架構過程需要進行歸納
對行為穩定性，效能考慮的總結，歸納為通用元件

架構輸出

方案概述：對設計方案的概括性描述
設計約束：包括要遵循的標準或規範，技術上依賴的假設條件等
技術選型：包括系統執行的軟硬體環境，研發、測試的軟硬體環境，程式語言，現有或開源框架、平臺、模組、基礎庫的重用策略
系統結構：包括系統的網路部署結構，子系統劃分。推薦用UML部署圖、包圖描述
關鍵技術設計：每個系統關鍵點不一樣，但一般都會有安全設計，一些演算法的設計
介面設計：包括協議棧，子系統間的介面資料結構，子系統間的業務流程描述。業務流程推薦用UML序列圖描述。
資料設計：流動的資料已透過介面設計，這裡描述要儲存的資料。資料的組織形式不一樣，比如NoSQL，NewSQL，SQL等不同型別，描述方式也會不一樣。關係資料庫推薦用ER模型描述頂層邏輯結構，欄位表描述物理結構。
質量預測：對遺留缺陷率、平均無故障執行時間等質量指標進行預測，提出可能出現的缺陷和問題。

總體架構輸出如下：

架構總結

自底向上：由點及面，步步為營，透過用例堆積，分類，歸納，劃分，內聚，逐步擴大範圍，再透過剝離，複用，從業務架構到技術架構。
自頂向下：洞察客戶背後的本質需求，定義問題，分析問題，問題分類，優先順序，升層思考，一上來自帶上帝視角。

實際應用，兩者結合。

6.5設計規範

建立用例後，由於對用例分析的方法差異可能生成不同的領域模型。

模型約束

推匯出模型過程中，需要參考業界沉澱出來的經驗，比如sold原則，開閉原則等

GRASP設計原則（職責分配原則）

資訊專家原則(information)

創造者原則(creator)

低耦合原則(low coupling)

高內聚原則(high cohesion)

控制器原則(controller)

多型原則(polymorphism)

純虛構(pure Fabrication)

中介原則(indirect)

受保護變數原則(protected Variations)

設計原則

GRASP原則，設計原則有很多，我們進行架構設計的主導原則是OCP（開閉原則），在類和程式碼的層級上有：SRP（單一職責原則）、LSP（里氏替換原則）、ISP（介面隔離原則）、DIP（依賴反轉原則）；在元件的層級上有：REP（複用、釋出等同原則）、CCP（共同閉包原則）、CRP（共同複用原則），處理元件依賴問題的三原則：無依賴環原則、穩定依賴原則、穩定抽象原則。這些原則是前人大量的經驗總結，比如設計模式的原則，SOLID是幾個重要編碼原則的縮寫：

開閉原則（Open Close Principle）開閉原則就是說對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的程式碼，實現一個熱插拔的效果。
里氏代換原則（Liskov Substitution Principle）里氏代換原則(Liskov Substitution Principle LSP)面向物件設計的基本原則之一。
依賴倒轉原則（Dependence Inversion Principle）這個是開閉原則的基礎，具體內容：真對介面程式設計，依賴於抽象而不依賴於具體。
介面隔離原則（Interface Segregation Principle）這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。
迪米特法則（最少知道原則）（Demeter Principle）為什麼叫最少知道原則，就是說：一個實體應當儘量少的與其他實體之間發生相互作用，使得系統功能模組相對獨立。
合成複用原則（Composite Reuse Principle）原則是儘量使用合成/聚合的方式，而不是使用繼承。

設計模式

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

建立型模式

簡單工廠模式（Simple Factory）
工廠方法模式（Factory Method）
抽象工廠模式（Abstract Factory）
建立者模式（Builder）
原型模式（Prototype）
單例模式（Singleton）

結構型模式

外觀模式（Facade）
介面卡模式（Adapter）
代理模式（Proxy）
裝飾模式（Decorator）
橋模式（Bridge）
組合模式（Composite）
享元模式（Flyweight）

行為型模式

模板方法模式（Template Method）
觀察者模式（Observer）
狀態模式（State）
策略模式（Strategy）
職責鏈模式（Chain of Responsibility）
命令模式（Command）
訪問者模式（Visitor）
調停者模式（Mediator）
備忘錄模式（Memento）
迭代器模式（Iterator）
直譯器模式（Interpreter）

七、架構落地

說了這麼多，架構如何落地的，相信這個是大家最關心的，前文我們已經從整體上建立了系統設計的方法論，在從it領域上升到通用商務領域的設計思維，在系統設計的層面又步步為營給出了工具和剖析模型建立架構推導的一步流程。其實到了這一步，架構設計已經到了柳暗花明的階段了，因為我們已經已經把最核心的環節都弄通了，接下來無非對症下藥，根據需求找到系統薄弱的地方，相應的使用適用的工具來發揮最大的作用。

行業架構

目前大部分行業其實都已經有相對穩定成熟的應用架構，也形成了基本的套路，比如金融行業有傳統的基於IOE的商業應用架構，也有新型網際網路的去IOE基礎上的架構，比如微服務化的流行，在即時通訊的訊息架構也是有成熟的解決方案。另外產業網際網路各個傳統行業的網際網路化也可以應用邊緣計算架構來實現。

技術架構

行業下沉到技術架構層面，從小微企業到大型企業應用的解決方案，都逃不過，閘道器設計，流量管理，服務治理，容錯設計，監控告警，效能調優，資料管理等環節，而這方面的設計實現業界也提供了成熟的開源解決方案，可以參考《分散式設計知識體系》一文，除了巨型企業需要自研外，多數開源的工具已經可以滿足大部分需求，那麼架構設計其實就是選擇最適當的工具來解決我們的問題。

八、總結

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

最後例行給出腦圖：