架構設計的本質

做者 | 編程原理林振華

【問題】

• 什麼是系統設計，系統設計的核心是什麼？
• 如何訓練系統設計的思惟模式？
• 有什麼方法來幫助咱們理解複雜的系統？
• 如何進行系統分析？
• 架構設計的本質是什麼？
• 如何進行架構設計？
• 如何進行業務領域建模？
• 模型如何推導出架構設計？
• 架構設計須要遵循哪些規範？

【關鍵詞】

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

全文概要

軟件從業人員的成長路線大致是在管理線和技術線上造成突破，固然也有結合起來相得益彰的。而技術上的追求，架構師則是一個重要的門檻，對於剛入行的程序員可能會認爲架構師就是畫架構圖的，誠然架構師很重要的一個職責是繪製架構圖，但這只是其中一個很小的環節而已。

實際上架構也只是系統設計裏面的一個重要環節，除了架構還包含了商業訴求，業務建模，系統分析，系統設計等重要領域。本文嘗試從更高視角從新審視架構設計的工做，把架構設計的上升到系統設計的立體空間去探索，最終勾勒出系統設計的全域知識體系。

思惟分析

1. 系統總覽

人類社會活動中的無論大大小小的，簡單抑或複雜的事物，總要先出如今咱們的腦海裏，而後再投射到現實的物理空間來。咱們老是在孜孜不倦地追求美好的事物，但現實存在的問題就是，首先咱們的腦殼也理解不了太過複雜的東西，其次腦海裏的想象有時候也很難真實無損的映射成現實的系統，再者因爲老是資源有限的，咱們並無花不完的預算。

歸結起來設計一個系統，或者樸素的說，作一件事情，咱們須要解決如下問題：

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

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

系統能夠分爲天然系統和人工系統，可是本文特指須要人類參與的人工系統。

天然系統：

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

人工系統：

• 機械系統
• 電子系統
• 操做系統
• 社會系統

2. 系統演化

上面談到在系統設計流程主要是使用了分析思惟和系統思惟的結合，固然人類思惟還有其餘的運做模式，好比批判思惟，創新思惟和發散思惟等，以此衍生的又是另一套大相徑庭的方法論。下面咱們主要分析系統設計過程當中的思惟活動。

一般談起架構師就會聯想到各式各樣的架構圖，談架構圖就要搞清楚什麼是架構設計，那麼架構設計以前是什麼呢？架構設計是整個系統建設的核心環節，猶如設計圖紙之於建築那麼重要，那架構設計之上應該就是系統設計了。先搞清楚系統設計的定義：

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

1）業務描述

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

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

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

因爲人命關天，這項工做看起來是挺複雜的，初次接到這個單子時我心裏是彷徨的。可是回答了以上問題後，感受明朗了很多，咱們在完成系統性質，受衆，利益和目標的分析和解答後，才能進入到系統的架構階段。

首先對以上提到的需求，咱們先用動畫片裏面的簡單畫面爲基礎來描繪咱們的設計，而後大體根據能想到的過程完成初次業務流程的描述。

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

經過以上的描述，基本涵蓋了火星旅程的四個階段：登機，航行，下機遊玩，返程，這本質上跟咱們平時搭個飛的去趟浪漫的土耳其也是差很少的。而在此以前咱們腦海裏可能仍是一片混沌，沉溺在登錄火星這項浩瀚的工程而不知道從而入手。

從混沌到開始有點頭緒，其實無形中已經完成了一次建模，咱們稱爲業務建模。翻回去查閱系統總覽的表格，其實咱們已經把需求這個維度大體列舉出來了，把登錄火星的幾大領域給分離開來了。那麼接下來就是要把登錄火星這個項目的主線給說明清楚。

2）概念抽象

怎樣把這件事的主線說明清楚？口若懸河的把一件事情講完其實反而是很難講明白，除非這件事情自己足夠很是簡單的。那麼就須要抓重點的來講，這個時候就須要一個叫作「概念」的工具。

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

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

這裏穿插講一下概念的應用，比「傅立葉級數」這個概念，我敢打賭有 80% 的人不知道所謂何物，可是不要緊，咱們並非要來科普這個概念，先根據百度百科來看看這個概念的描述：

先不要怕，我這麼說的目的不是爲了讓你們搞懂什麼是傅立葉級數，這裏咱們能夠看出即便這麼鬼畜概念也是很普通的基礎概念元素組成的，好比收斂公式，好比三角函數，好比 Σ 求和概念，甚至像 1，2，3 這些阿拉伯數字。這裏不得不說學數學最核心的環節就是深入理解概念，沒有之一。

說回來，這裏的語境就是在你們都共同理解接受這些基礎概念後，通過一系列複雜組合的高級概念，也依然可以清晰嚴謹的表達出來，下面傅里葉級數的產生過程的動圖看看就好。

好了，如今咱們知道了概念這個工具的重要性和功能，前面咱們已經列舉了登錄火星要作的事情，那麼如今就須要精確簡潔的把這件事給說清楚了，這個是個困難的任務，由於若是主線沒有梳理清晰，後面整個工程將萬劫不復。

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

3）系統落地

固然這還遠遠不夠，系統之因此複雜，就是咱們對系統總有無數更多的要求，更多的功能，更好的性能，那麼接下來就是對各個模塊進行分析，細化，設計和實施。固然咱們不會班門弄斧真的在這裏去分析登錄火星的實際流程，以上這個例子雖然比較粗曠，可是基本也描繪了一個複雜系統建設的過程，也就是從需求，建模到架構的思惟過程，是從最原始的登火需求一步步擴展的過程。

其實咱們還能夠舉個小一點的案例，好比一個有趣的需求「賺錢」，引伸出來就是作一個能盈利商業項目架構，有興趣的同窗能夠根據這個思惟模式一步一步勾畫出整個流程出來，相信這也是一個不錯的方法，也許還真能解決些許困惑。下面演示的就是登月過程宏觀層面落地的步驟。

3. 架構思惟

1）架構目標

一直以來我聽過不少人在講架構，有些人在作架構，可是很難討論出一個你們都滿意的定義，什麼是架構師，架構師須要作哪些工做？或者說不多有往深的去思考，只知道被稱爲架構師說明這我的很厲害。在我畢業的時候有個同窗打趣的跟我說，大家作程序的無非就是增刪改查，當時我竟無言以對，當時腦海裏浮現的是一系列工具的應用技巧，好比 tomcat，nginx 的使用，還有對業務的翻譯。

隨着對業務的貼近和對計算機技術的進一步認識，我從新審視「這世上的系統無非就是增刪改查」，這句話說對也對也不對，這句話就跟計算機軟件無非就是 0 和 1 的集合，也對也不對。特別是對剛入行的人可能以爲設計離本身比較遠，由於習慣了打開 idea 纔開始考慮業務，寫代碼纔開始思考領域模型，這是很是很差的習慣，好像若是沒有在 coding 狀態下是沒法進行建模思考，這個很難，須要持久的訓練才能達成設計階段進行思考。

架構設計只是系統設計裏面的一個階段，而系統設計是應用建設裏面的核心環節，有一些簡單的應用建設是不須要系統設計的，固然有一些複雜的應用，在能力超強的工程師團隊，有足夠的默契後，也能夠直接進行建設。

軟件架構之道最核心的問題是解決複雜性的問題，而且在解決問題的過程當中找到最佳的平衡點，既要簡單又能知足發展。描述系統設計的本質，就是實現縱向上的時間，橫向上的空間進行考慮，規劃出決策路徑，最終拿到目標結果。

架構師眼裏第一件事不是多流行的技術，多高性能的框架，或者多完善的業務模型，而應該聚焦在利益之上。對，這個可能會顛覆一些認知，當咱們真正把利益放在首位後，再去考慮接下來要完成的事情，咱們的工做才能稱得上架構。也就是說，架構師的天職就是最大限度地實現客戶的利益，這裏的客戶能夠是市場客戶，也能夠是協做團隊，還能夠是同一個團隊的項目成員。

再直白的說，架構師就是負責把老闆畫的餅給實現了，在至關長的一段時間內保證產物有足夠的利益回報。有人會說那咱們作的就是公益項目，就不考慮利益，我補充一下，這裏說的利益不止是經濟收益，還有系統帶來的社會價值。那麼又有人會說，架構是追求利益回報，那老闆的目標就是炒股發大財，請架構師你給我選幾支股票吧，那我會說其實優秀的基金經理也能夠稱爲廣義上的架構師。

2）架構過程

天然在增熵，而系統架構過程其實就是減熵的過程，一個架構的誕生始於目標的確立，而後是對需求的刻畫，繼而是落地方法的抉擇。

所謂條條大路通羅馬，有的是一路平川而有的則是崎嶇不平，那麼架構過程就是不斷歸類合併同類項，力求最合適的決策選擇來實現咱們所要達成的願望。在面對複雜業務的場景下，咱們須要作出以下的思考：

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

在架構過程當中，很重要的一項任務就是識別系統的實體關係和功能關係，進而對系統效果進行預測，也就是在完成一系列的分析建模工做後推導出來的系統架構須要在預測上達到咱們要的效果，那麼系統預測一般有以下四種方式：

• 經驗
• 實驗
• 建模
• 推理

3）系統思惟

系統思惟不等於系統化思考，與系統思惟並列的能夠是批判思惟，分析思惟，創新思惟，而咱們追求的是元認知，也便是認識到本身處於何種思惟模式。系統思惟目標：

• 理解系統是什麼
• 預測系統的走向
• 爲決策提供知識支持

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

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

系統分析

上一節談論了系統設計的心智模型和投射到物理世界的演化規律，但前提是創建在已經具有豐富系統設計經驗基礎上。而在進行系統架構以前，須要先對系統分析有必定的理解，比如咱們製造發動機以前，得先把發動機拆下來好好研究一番，直接上來就要設計出發動機有點像空中樓閣。

本節將提供一套基礎的方法，來對現有系統進行分析，得出一些系統架構相關的推論。按照慣例須要先搞清楚系統分析的概念：

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

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

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

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

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

1. 實體分析

實體指系統物理時空存在的單元，彼此經過必定的結構造成系統，那麼在分析實體以前，咱們能夠帶着下面的問題進行分析：

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

實體是系統的一項基礎屬性，是系統的物理體現或信息體現。對功能的執行起工具性做用，而描述實體一般能夠使用如下工具來表達：

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

實體之間的關係就是結構，分析結構時須要對實體進行分解，實體能夠建模爲對象及其之間的結構，進一步能夠分解爲小的實體，又能夠聚合起來稱爲系統自己，對實體之間的各類結構分析則能夠得出系統架構，便是把功能元素組合成物理塊時所用的編排方式。

1）分析實體

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

2）分析關係

便是實體的結構，是對象之間存在穩定關係，有助於功能交互的執行系統實體有以下關係：

• 空間拓撲關係
• 鏈接性關係
• 地址關係
• 順序關係
• 成員關係
• 全部權關係
• 人際關係

2. 功能分析

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

關於系統功能其實能夠樸素的認爲就是動賓短語的集合，功能=動詞+賓語，含義就是實體狀態變化的過程，就是功能的體現，具體分析下文會詳細展開。功能 = 主體 + 操做 + 操做對象，好比嘴巴有「吃飯」功能，飛機有「搭載乘客」功能，報表平臺有「展現報表」功能。

• 操做：對象經歷的一種轉換模式，過程設計操做數的狀態變化；

• 操做對象：操做數是一個對象，在某段時間內穩定且無條件存在，操做數不須要先於功能的執行而存在，操做數可能會由功能中的過程部分來建立，修改或消耗。

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

系統設計

通過了上幾節的思惟訓練和系統逆向分析，咱們也大概理解了系統設計的流程和系統架構的造成過程，本節將介紹系統設計，包括設計工具，需求分析，模型創建，架構推導，設計規範完整的系統設計流程。

系統設計，即設計出一套良好的系統架構，就是構建一套具有必要複雜度又不難懂的系統。下面在介紹方法論的同時，同時會穿插一個數據平臺的大體設計過程。

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

TOGAF：框架開放組體系結構框架（The Open Group Architecture Framework，縮寫：TOGAF）是一個企業架構框架，它提供了一種設計，規劃，實施和管理企業信息技術架構的方法。TOGAF 是一種高層設計方法。它一般被建模爲四個級別：業務，應用程序，數據，和技術。

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

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

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

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

企業能夠經過應用企業架構開發方法（ADM）來建設各類業務能力，下面咱們再來介紹另一種系統設計的思路。

1. 設計工具

工欲善其事，必先利其器。前文講到思惟分析，不一樣思惟模式決定不一樣的方法論，那麼在分析思惟層面，人類大腦其實很難理解太過複雜的東西，這個時候就須要藉助一些工具來協助思惟的活動。

首先第一工具固然是語言，這個不用多說，沒有語言做爲基礎將步履維艱，單個體的時候語言用於描述系統的訴求，而多個體的時候語言則扮演着溝通的角色，可是若是語言不互通的話可能就像雞同鴨講。即便是同一種語言，不一樣的表述都會造成很大的誤差，那麼就須要一種廣泛承認的統一語言，在系統分析審計領域，咱們首推統一建模語言（英語：Unified Modeling Language，縮寫 UML），固然還有其餘好比 SYSML 或者 OPM，下面咱們先大體介紹下 UML，列出 UML 的核心語言元素，視圖，模型和過程。

1）核心元素

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

2）核心視圖

靜態圖包括：

• 用例圖
• 類圖
• 包圖

動態圖包括：

• 活動圖
• 狀態圖
• 時序圖
• 協做圖
• 泳道圖

3）核心模型

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

4）核心流程

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

5）軟件工具

• draw.io
• StarUML
• Visual Paradigm

2. 需求分析

本節不打算講需求分析師的工做流程，由於咱們已經很熟悉需求分析師對需求的分析過程了，因此無需多言，在講需求以前咱們先來看看架構師須要完成的工做。

架構師並非全能的通才，沒法瞭解全部細緻的需求，因此架構師要作的就是簡化系統的複雜度，消除業務歧義，致力於輸出健壯兼容的系統架構。因爲系統需求分析須要由架構師這個角色全程參與，深度理解業務，下面咱們簡單對架構師角色進行討論。

1）架構角色

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

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

系統分析師：是在信息系統研發中，負責經過需求分析確認系統的需求，並進而造成系統產品設計的人。一般他們也會涉及可行性評估、項目管理、開發前評估、需求驗證等工做。

傳統意義的系統開發分爲系統架構師和系統分析師兩個角色，可是隨着互聯網的快速發展，現在系統建設愈來愈趨向於將兩個角色結合起來，那麼互聯網時代架構師有以下職責：

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

架構師是軟件開發活動中的衆多角色之一，它多是一我的、一個小組，也多是一個團隊，咱們分析的是架構師這個角色，能勝任這個角色的纔是架構師，那麼在這個角色上能作得更加出色的就是好的架構師。

以上架構師職責是總體上的描述，在細分領域有不一樣的分類。微軟對架構師有一個分類參考，咱們參考一下，他們把架構師分爲 4 種：

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

既然對架構師角色有諸多要求，那麼也能夠來概括一下架構師必備的一些技能，能力模型能夠參考《職業成長的邏輯模型》一文中對能力模型的描述，架構師能力要求：

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

2）利益分析

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

不忘初心這一點尤其可貴，不少項目作着作着就偏離了當初的目標，這個過程咱們必定要牢牢抓住系統最重要的受益者，梳理好系統衆多涉衆的利益分配。

3）資源評估

資源評估不只僅是項目經理的事，並且仍是對團隊資源的評估和編排，好比某項業務技術團隊中研發和數據人員的配比，決定了數據平臺投入的資源範圍，這要求架構師在作設計分析的時候須要充分考慮到資源的利用效率，包括人力資源和機器等資源。

4）需求規範

用戶的訴求體現爲需求的輸出過程，不一樣層次分解需求得出了不一樣的複雜度，咱們知道架構師的一項重要職責就是消除歧義，精準的把握需求來匹配用戶的訴求。那麼就須要一系列規範來保障需求採集的過程當中不失真。

下面列出了需求採集過程的一些指導原則：

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

5）需求描述

在進行需求描述時，咱們能夠從多個角度來審視需求是否合理地表達出來：

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

6）需求採集

回到咱們平臺設計的案例上，通過用戶訪談粗略的採集的需求：

• 單項業務壁壘是個困局，本質上是功能缺陷，打通數據壁壘 • 業務各個階段的數據管理，要對數據底層進行管理 • 須要對由相同特性的報表實現快捷地生成

需求背後：

• 能夠一次性看更多的數據 • 能夠方便的切換數據 • 能夠更快的看到數據

so，這個真的是客戶想要的嗎？總體上，用戶想看什麼數據？同時我也在思考下面的問題：

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

3. 模型創建

在系統設計這個階段，咱們已經介紹瞭如何運用工具，還有用戶需求的管理，接下來就是要把需求「消化」成咱們須要的架構。可是架構不是無緣無故就產生的，前文咱們用登錄火星的案例也大概描述了系統的建設過程，那麼在推導出架構以前，把用戶不那麼清晰的訴求轉化成嚴謹的業務概念模型就頗有必要了。

1）模型基礎

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

模型：是指用一個較爲簡單的東西來表明另外一個東西。

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

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

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

2）建模目標

便是說業務建模是一種建模方法的集合，目的是對業務進行建模。這方面的工做包括了對業務流程建模，對業務組織建模，改進業務流程，領域建模等方面。針對複雜難懂的系統，咱們構造出一個比較簡單的模型，來表明複雜的業務，這個是一種有效的辦法，這也是咱們須要建模的緣由，隨着計算機的飛速發展，或許之後計算機能夠幫人類承當一部分的設計工做，而計算機是不怕複雜業務的，也許那個時候就再也不須要這種特意適應人類思考的模型了。

創建模型不是最終目的，而是把複雜的業務訴求構建成簡單的業務概念，在軟件開發團隊溝經過程中能造成共識，消除歧義，並且信息傳遞不失真，爲輸出架構奠基基礎。

3）模型分類

在業務不一樣的階段，一般會使用不用的模型來表達，通常狀況下咱們把模型分爲：

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

4）建模方法

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

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

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

5）用例驅動

用例驅動是一種由外而內，先招式後內功的思想。咱們先從涉衆對系統的指望開始，定義出系統如何知足他們的願望。這一過程是感性的、外在的、符合當前需求的。

用例驅動的結果是咱們的軟件是以實現一個個場景爲目的的，認爲當一個系統的行爲知足了全部涉衆的指望以後，即知足了涉衆使用系統的場景以後，該系統就是一個成功的系統。

【創建用例】

用例定義：工具—>過程—>操做數 （主 謂 賓）

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

【用例規範】

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

【建模過程】

• 用例模型

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

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

用例有嚴格的規範，回顧上文系統分析裏面，咱們對系統功能分析給出一個公式：功能 = 主體 + 操做 + 操做對象。用例也是須要這樣的結構，好比「我愛你」是完整的用例，能完整的描述一件事情，而「愛你」則不能稱爲一個用例。因此用例模型創建階段就要力求把用戶訴求都完整的以用例表達出來。

• 業務模型

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

咱們在數據平臺對用例模型進行抽象。

**分析師 **爲客戶 製做 業務 報表：

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

• 主語：分析師
• 狀語：客戶
• 謂語：製做
• 定語：某一項業務
• 賓語：報表

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

• 概念模型

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

如今咱們明確了業務模型後，接着就是細化用戶，補充更多的細節：

• 分析師 爲 不一樣的客戶  製做  不一樣業務的 報表
• 分析師 爲 不一樣的客戶  製做  幾款業務的 報表
• 分析師 爲 不一樣的客戶  製做  一項業務不一樣區域的 報表
• 兩個分析師 爲 某個羣體用戶  製做  業務線的 報表
• 客戶 受權 某個羣體  查看  不一樣業務的 報表

結合咱們對業務的瞭解，能夠豐富領域的屬性，還有一個隱性的「權限」名詞，咱們須要獨立出來，由於權限不屬於任何一個領域。

一般咱們須要角色概念來管理用戶訪問報表的權限。

• 管理員 爲 不一樣的客戶  建立  一項業務不一樣區域的 角色

• 管理員 爲 不一樣的客戶  分配  一項業務不一樣區域的 角色

• 小二 爲不一樣報表  建立  不一樣  權限

• 系統模型

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

豐富業務場景後，總體的用例以下圖：

• 分析師 爲 不一樣的客戶  製做  不一樣業務的 報表
• 工程師 爲製做 個性  報表
• 小二 給不一樣業務建立報表模板 來生成報表
• 小二建立權限 來 匹配報表
• 客戶建立角色
• 客戶分配角色
• 客戶篩選人羣進行營銷活動
• 前置條件：業務告警？

6）領域驅動

用例驅動是一種從局部到全體的思惟方式，剛剛接觸某一行業的人員從零開始來了解業務，複雜業務很難一開始就擁有上帝視角來分析業務。而領域驅動則是一開始就站在上帝視角來着手業務，領域驅動要求化整爲零，它是一種由內而外，先內功後招式的思想。它要求團隊裏有資深的業務領域專家，該專家對業務領域極其瞭解，不但要了解其然，還要理解其因此然，或者是可以跟領域專業人員學習到足夠的領域知識。

在此條件下，團隊將從業務領域裏找出反映業務本質的那些事物、規則和結構，把它抽象化，描述業務運行的基本原理和業務交互的機制，識別出用戶的首要利益。

領域驅動須要領域專家深度參與，訪談專家，纔可能得出領域模型，單靠技術人員自己很可貴出完成得領域模型。語言就是承載思想或者想法的模型，不一樣的語言建模出不一樣的思想，中西語言差別造就思惟差別，因此領域模型須要從語言談起，用語言描述事物。領域模型本質上傳遞的是概念，是知識性的信息，語言正是讓知識傳遞成爲可能。

對於軟件開發的場景來講，把這些知識顯式化，能快速對齊不一樣角色、不一樣參與方之間的概念，加速溝通，避免誤解。

【領域模型】

咱們先得搞清楚領域模型的概念，而後纔有領域驅動。

領域模型是採用業務對象創建起來的一種模型，咱們把領域模型當中使用到的業務對象稱爲領域類。

回顧咱們學了不少年的面向對象變成設計，而實際上真正使用面向對象開發的思惟倒是比較稀少的，好比傳統 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 中最多見的一類設施是對象持久化的具體實現。

【建模過程】

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

• 用戶訪談：充分貼合業務，基於現有人員資源能力；

• 領域知識：首先咱們分析項目在領域分層後的概念項目涉及到：

  • 名詞：分析師，工程師，客戶，小二
  • 報表，報表模板，權限，角色，告警，人羣，活動，決策
  • 動詞：登錄，建立權限，匹配權限，受權，建表，圈人，營銷
  • 實體：報表，報表模板，權限，角色，人羣，活動，決策
  • 值對象：告警
  • 服務：登錄，建立權限，報表匹配權限，受權給用戶，建立報表，圈人，營銷
  • 模塊：報表域，權限域，洞察域，營銷域
  • 聚合根：報表（報表模板，報表數據），權限（權限，角色），活動（人羣，營銷規則）
  • 工廠：報表模板工廠，人羣工廠，決策工廠，權限工廠
  • 資源庫：數據庫，消息，外部接口

• 領域模型：通過對領域知識的消化，就能夠輸出領域模型圖。

4. 架構推導

通過了漫長的前戲--模型創建，本篇終於到了架構設計了，真的不容易啊。一開始我老是在糾結架構師應該輸出什麼架構圖，什麼纔是標準的架構圖，可是當我理解什麼是架構，架構造成的過程後，我再也不糾結了，架構存在每個階段，以不一樣的形態出現，業務，產品，技術，實施不一樣的階段都須要一張提綱挈領的架構圖來指導系統建設。

系統架構這個詞常常放在一塊兒說，以致於咱們以爲天經地義，常常混爲一談。系統指的是由一堆實體組成的一個具有某些功能的總體，而架構則是架和構，便是框架和結構，也就是具有穩定訴求並且是能夠支撐總體的組件。系統能夠沒有架構，好比咱們亂糟糟的系統。可是系統同時也是須要架構的，架構就像是系統的 DNA，架構決定了系統的走向和生命週期，好的架構能夠支撐系統持久運行和更新迭代。

1）架構定義

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

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

2）架構分類

隨着互聯網的發展，應用從單體到分佈式，到現在基礎設施的變革，咱們迎來了雲原生時代，系統的架構隨着基礎技術的突破也不斷演化，單體應用最簡單最多見的架構就是分層架構，好比咱們熟悉的 MVC 架構，因爲業務發展到必定層度後，須要對服務進行解耦，進而把一個單一的大系統按邏輯拆分紅不一樣的子系統，經過服務接口來通信，面向服務的設計模式，最終須要總線集成服務，並且大部分時候還共享數據庫，出現單點故障的時候會致使總線層面的故障，更進一步可能會把數據庫拖垮，因此纔有了更加獨立的設計方案的出現。

隨着分佈式技術的成熟，微服務架構開始大行其道，在此基礎上的邊車服務和 servicemesh 也開始進入蓬勃發展期，總體上架構有以下分類：

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

3）推導架構

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

• 演繹

  • 將用例進行抽象分類成爲業務模型
  • 將業務模型進行 IT 層面的思考，增長非功能性的組件造成系統模型

• 概括

  • 將用例以及問題進行分類聚合
  • 業務用例造成系統架構過程須要進行概括
  • 對行爲穩定性，性能考慮的總結，概括爲通用組件

4）架構輸出

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

5）架構總結

• 自底向上：由點及面，步步爲營，經過用例堆積，分類，概括，劃分，內聚，逐步擴大範圍，再經過剝離，複用，從業務架構到技術架構；

• 自頂向下：洞察客戶背後的本質需求，定義問題，分析問題，問題分類，優先級，升層思考，一上來自帶上帝視角。

實際應用，二者結合。

5. 設計規範

創建用例後，因爲對用例分析的方法差別可能生成不一樣的領域模型。

1）模型約束

推導出模型過程當中，須要參考業界沉澱出來的經驗，好比 sold 原則，開閉原則等：

• GRASP 設計原則（職責分配原則）
• 信息專家原則(information)
• 創造者原則(creator)
• 低耦合原則(low coupling)
• 高內聚原則(high cohesion)
• 控制器原則(controller)
• 多態原則(polymorphism)
• 純虛構(pure Fabrication)
• 中介原則(indirect)
• 受保護變量原則(protected Variations)

2）設計原則

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）：該原則是儘可能使用合成/聚合的方式，而不是使用繼承。

3）設計模式

在編碼過程當中，前人抽象出來的 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 領域上升到通用商務領域的設計思惟，在系統設計的層面又步步爲營給出了工具和剖析模型創建架構推導的一步流程。

其實到了這一步，架構設計已經到了柳暗花明的階段了，由於咱們已經已經把最核心的環節都弄通了，接下來無非對症下藥，根據需求找到系統薄弱的地方，相應地使用適用的工具來發揮最大的做用。

1. 行業架構

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

2. 技術架構

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

總結

系統設計猶如醫生看病須要對症下藥，醫生須要博學多才精通藥理，才能對症下藥，就像架構師經驗豐富，懂得各類軟件工具（藥）的利弊，各類設計原則和設計理論（藥理）能夠設計出架構圖（藥方），把軟件工具精妙的組合在一塊兒。

學習的最佳方式是先進行比喻，其次是模仿，最後迴歸到概念的本質定義。一個好的軟件架構師，一樣可能成爲很好的 hr 專家。本文共分爲三個部分從思惟講起到系統逆向分析，到後面的正向設計。從「道，理，術」三個角度詮釋了系統架構設計的全面知識體系。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」