概述

首先，系統是什麽？根據《系統架構》一書的定義，系統是由一組實體和這些實體之間的關系所構成的集合，其功能要大於這些實體各自的功能之和。對於我們的場景，系統可能是 App、Web 應用、服務、批處理程序等，也可能是包括所有這些的一個大系統。

隨著互聯網和傳統企業的結合越來越深入，業務會越來越復雜。我們該如何設計我們的系統呢？

從產品到研發

從產品作出原型，到研發編程實現，中間有巨大的鴻溝。越復雜的業務需求，這條鴻溝就越大。一般而言，我們至少還要有兩個步驟：業務分析與架構設計。

業務分析，主要處理的是業務領域的建模。解決的問題是業務上如何實現。然後是技術與架構方面的設計，主要針對的是技術實現，解決的問題是技術上如何實現。這兩個方面是會互相影響的，設計的時候往往需要來來回回的考慮這兩個方面。甚至系統開發時也時常會需要調整模型或者架構，當然相應的也需要更新文檔。

基本原則

設計與分析的過程就是不停的進行抽象和封裝，並且確定各個系統實體的細節。抽象是指將業務抽象為軟件領域的元素（系統、模塊或類）；封裝則是指定義元素的邊界，隱藏實現，開放接口。

相應的，分析與設計時，最基本的原則就是抽象性和封裝性。當然，我們有 SOLID、DRY、高內聚低耦合、設計模式等各種原則和方法，具體方式本文不詳述了，但最終它們都可以歸類到以上兩點。

業務分析

分析方法

業務分析是針對業務領域的建模，產出就是分析模型。分析模型描述系統的邏輯設計與結構，一般會包括需求用例、實體模型以及業務場景的交互流程、狀態轉換等。分析模型讓非技術人員能夠理解系統是如何構造的，讓技術人員能夠以此為基礎搭建系統。

分析的過程是不斷叠代的。特別對於復雜的、涉及多個業務領域的需求，第一步往往需要在整體系統的層級進行分析，然後將模型劃分到多個子系統，然後再在子系統的層級進行更細節的分析與建模。

另一方面，分析過程中需要不斷的優化和調整。例如在確定實體的行為細節時，發現兩個實體的耦合很高，那麽可能需要重新進行抽象，調整實體的功能範圍。

理清業務需求

理清業務需求是所有分析與設計的前提：

• 確定系統的利益相關者（Stakeholder）及他們的關註點。

• 確定系統的業務需求，即「誰」使用該系統「做什麽」。

• 確定系統的功能範圍，即該系統「包含什麽」，不包含「什麽」。

系統需要滿足利益相關者的關註點，所以要確保所有這些關註點都有涉及到。最重要的利益相關者當然就是用戶（有時還會細分為不同類型的用戶），此外還應該包括供應商、合作方、運營、銷售、老板甚至政府等等，也同樣包括研發測試和運維。

具體到系統的用戶，還需要細分到角色，即使有些角色實際可能是同一個人。比如對於門診，可能有護士、顧問或系統管理員等等，可以進行不同的操作。需求範圍簡單話用一個列表即可，復雜的系統可以考慮使用用例圖。

例如，門診預約系統的用例圖可以這樣畫：

• 角色有醫生、患者和門診員工。

• 用例有設置排班、管理預約以及預約/取消醫生。

建立實體模型

實體模型是確定系統包含的實體以及它們之間的關聯的過程：

• 理清業務概念，統一業務詞匯。

• 抽象業務實體，包括事件、人/角色、地點和事物等。

• 識別實體關系：繼承、聚合、關聯等。

實體模型也叫 ER（Entity-Relation）模型。可以考慮使用四色法建模，一般可以使用類圖或組件圖表示。需要註意的是一定要理清業務的概念，統一命名和定義業務相關詞匯，這是進一步溝通的基礎。

例如，預約系統的實體關系圖可以這樣畫：

分析業務場景

場景分析用於確定具體業務場景中，各個參與者的交互過程，從而進一步完善分析模型：

• 分析具體業務場景，確定業務規則，梳理業務流程。

• 如果涉及復雜的狀態轉換，需要確定狀態轉換邏輯。

• 補充和完善實體模型的內容描述。

對於一個業務場景，參與者可能包括人、內部模塊、外部服務等，這一步需要理清楚整個業務過程和規則。需要註意的是，對於一些次要路徑或者異常路徑，也一定要考慮到。對於業務過程和規則，可以使用普通的流程圖、泳道圖，也可以考慮UML的活動圖，狀態轉換過程則可以通過UML的狀態圖展示。

對於場景分析中不太確定的需求，或者可能會有技術難點地方，可以記錄下來，後面確認和驗證。

例如，下面是預約系統的預約狀態圖。

例如，下面是我們和一家藥品供應商對接的流程圖。

架構與技術設計

架構方法

架構設計不一定要深入到具體的實現細節，但是應該盡量全面的考慮系統的各個方面。關鍵是要對項目風險有比較大的把握，這樣才能避免開發過程出現不可控的問題。具體設計需要多詳細，是需要設計者自己去把握度的。

對於暫時無法確定的內容，應該在文檔中註明，在開發過程早期進行試驗和驗證。如果對項目比較關鍵，可以考慮先行開發原型來進行驗證。

架構設計常見的是4+1視圖，即邏輯視圖、開發視圖、過程視圖、物理視圖，再加上場景。另外一種我更喜歡的是視點和視角的方法，如果再加上場景的話，可能會更全面。

確定整體架構

首先需要在整體上考慮系統的位置和職責：

• 確定系統在整個上下文中的位置，與其他系統的關聯。

• 確定系統自身以及各個外部系統的職責。

整體架構對應的就是情景視圖。這一步將系統看作一個黑盒，確認系統自己的範圍和職責，相關的外部系統的職責，以及他們之間的關聯。

例如，交易系統的整體架構大概是這樣的：

設計功能模塊

其次需要確定系統內部的功能模塊及其職責：

• 確定系統的模塊劃分。

• 確定每個模塊的職責以及模塊間的關聯。

功能模塊對應的就是功能視圖。這一步需要明確系統的內部結構。內部模塊劃分主要有基於業務功能的劃分，以及基於實現層次的劃分，稍復雜的系統可能會兩者都有。也有一些系統會采用CQRS等架構，那麽模塊劃分可能會不一樣。功能模塊可以使用UML的組件圖表示。

明確架構關註點

然後需要確定系統架構的理念：

• 理清架構設計需要考慮的關註點。

• 確定系統的架構設計上的取舍。

這一步需要考慮各種架構視角，主要有(但不限於)以下關註點：

• 安全性：身份驗證、權限控制和授權、操作日誌、安全審計、數據一致性等。

• 性能：響應時間、吞吐量等。

• 穩定性：停機時間、故障恢復、數據一致性、數據備份等。

• 擴展性：未來可能的變更，以及如何應對變更。

• 其他：國際化、易用性、合規性等。

以上所有的關註點，和開發資源、時間、範圍各個方面，往往很難同時滿足，所以必須要明確哪些是關註的重點，哪些則可以有所妥協。例如，為了滿足性能要求，可能需要降低數據的一致性；為了合規性，可能不得不花更多開發時間。

對於未來可能的變更，也一定要考慮到。通常情況下，我們至少要考慮未來半年的架構，但可能只實現當前需要的版本，但是確保未來可以很容易的擴展。

一旦確定了關註的重點，在設計和開發的每個過程中，我們都要把這個重點放在心上。

例如，對於訂單系統，因為涉及到錢和交易，數據的一致性和可追溯性極其重要。下單和支付的API都必須是冪等的，每一筆收入變動都必須記錄日誌，必須有嚴格的核對和對賬。為了安全，每一次API調用都必須進行權限驗證。

例如，亞馬遜有個知名的原則，所有的系統間調用都必須通過定義清楚的 API，不允許共享數據庫。這也是一個架構原則。

設計數據庫模型

如果分析時有了完善了實體模型，設計數據庫模型就不是什麽難事了。開發完成後，數據庫模型應該以數據庫為準，架構文檔就不需要保留這一部分了。

需要註意的是，數據庫模型是實體模型在關系數據庫的實現，但不一定是嚴格的映射。數據庫可能會有範式、冗余、一致性、同步、分表分庫方面的考慮，必要時可能會使用非關系型數據庫如ElasticSearch、Cassandra等。

有時候還會涉及到數據處理的流程。例如，一張圖片提交後可能需要進行預處理，然後有運營人員進行審核和標記，最後進行發布。過程中數據的保存形式或者狀態標記可能是不一樣的。

數據庫設計的更多規範可以參考數據庫規範。

設計接口

然後就需要確定 API 細節了。一般我們的服務的 API 是 JSON 格式 HTTP 形式的請求和回調。API 可能是接口定義，也可能會有其他接口形式，例如消息隊列等。設計階段，API 文檔可以通過 Markdown 文檔、RAP 等記錄，開發完成後可以獨立維護，或者使用 Swagger 和代碼一起維護。

接口設計需要註意幾點：

• 接口的設計應該以系統提供的領域資源或服務為基礎，同時考慮調用方的需求。

• 接口的粒度很重要，太細則調用方很不方便需要多次調用，太粗則無法靈活的滿足各種需求，需要仔細權衡。

• 接口的設計也需要從調用方的角度考慮如何進行調用。必要的話可以畫流程圖、時序圖、狀態圖詳細說明調用順序即狀態轉換等。

• 接口的文檔一定要清楚的說明調用接口的方法、前置條件，參數作用、不同條件的處理、返回接口等。

場景實現

一般情況下，有了業務場景分析，有了數據庫模型和 API，系統的實現一般是比較簡單了。但可能還會有一些細節需要進一步考慮實現細節，以避免風險。可以考慮更細節的活動圖、時序圖甚至偽代碼。例如：

• 復雜業務場景的詳細設計，或者復雜算法的實現描述。

• 離線任務的執行方式、時間和步驟。

• 非業務的一些場景，例如網絡斷開、緩存失效、第三方系統宕機等。

例如，對於支付系統的微信 Web 支付過程，涉及系統較多，交互比較復雜，可以通過時序圖來定義清楚：

其他考慮

對於我們的後臺系統來說，基本的技術框架都已確定，可以解決很多基礎的非業務需求。不過設計系統時，也還是需要考慮以下等方面：

• 通用處理的方式，例如日誌、錯誤處理、代碼規範、單元測試等。

• 數據遷移、同步和回滾方案：對於老系統的重構，需要仔細考慮並且提前演練。

• 系統部署和發布：如果系統涉及多個子系統，需要考慮系統的部署架構。特別是同時涉及到數據遷移的，一定要仔細考慮發布的過程。

• 系統監控和告警：除了常規的監控和告警，是否有特殊的指標需要監控？

• 並發和數據量：如果系統可能面臨對高並發和大數據量的問題， 需要設計對應的方案，以及相關的性能測試和壓力測試。

• 緩存設計：如果需要使用緩存，除了要考慮緩存的選型、方案，而且要把緩存放到整個系統中去進行設計。

• 技術選型：涉及到新技術的引入時，則需要仔細分析備用技術的優缺點，選擇最合適的方案。

設計方法和工具

• UML

• 面向對象設計（OOAP）

• 領域驅動設計（DDD）

• CQRS & Event Sourcing

參考

書

• 分析模式：可復用的對象模型(https://book.douban.com/subject/4832380/)

• 軟件系統架構：使用視點和視角與利益相關者合作(https://book.douban.com/subject/24530471/)

• UML和模式應用(https://book.douban.com/subject/1792387/)

• 架構即未來：現代企業可擴展的Web架構、流程和組織(https://book.douban.com/subject/26765979/)

文章

• 從用例分析到方案評審，我們是如何進行業務系統設計的(http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg)

• 互聯網公司研發RD如何撰寫總體設計與詳細設計文檔(http://www.10tiao.com/html/249/201412/201657741/1.html)

• 用UML做好系統分析(http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis)

• 運用四色建模法進行領域分析(http://www.infoq.com/cn/articles/xh-four-color-modeling)

• 從“四色建模法”到“限界紙筆建模法”(http://insights.thoughtworkers.org/paper-pen-modeling/)

• 淺談我對DDD領域驅動設計的理解(http://www.cnblogs.com/netfocus/p/5548025.html)

• 領域驅動設計參考架構詳解(http://blog.csdn.net/bluishglc/article/details/6681253)

• 領域驅動設計和實踐(http://www.infoq.com/cn/articles/cjq-ddd)

• 我對CQRS/EventSourcing架構的思考(http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027)

• 架構設計基礎知識整理(https://blog.dreamtobe.cn/2016/03/09/oo_architecture/)

如何進行系統分析與設計