如何進行系統分析與設計

概述

首先，系統是什麼？根據《系統架構》一書的定義，系統是由一組實體和這些實體之間的關係所構成的集合，其功能要大於這些實體各自的功能之和。對於我們的場景，系統可能是 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

參考書

分析模式：可複用的物件模型( )
軟體系統架構：使用視點和視角與利益相關者合作( )
UML和模式應用( )
架構即未來：現代企業可擴充套件的Web架構、流程和組織( )

文章

從用例分析到方案評審，我們是如何進行業務系統設計的( http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg )
網際網路公司研發RD如何撰寫總體設計與詳細設計文件( )
用UML做好系統分析( )
運用四色建模法進行領域分析( )
從“四色建模法”到“限界紙筆建模法”( )
淺談我對DDD領域驅動設計的理解( http://www.cnblogs.com/netfocus/p/5548025.html )
領域驅動設計參考架構詳解( http://blog.csdn.net/bluishglc/article/details/6681253 )
領域驅動設計和實踐( )
我對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/ )

作者：章燁明，杏仁醫生CTO。中老年程式設計師，關注各種技術和團隊管理。
出處： https://mp.weixin.qq.com/s/JoKzg2vUe2IwX099xSFtFA