複雜系統分析與設計思路

概述

 

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