概述

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括卓尼網(wǎng)站建設(shè)、卓尼網(wǎng)站制作、卓尼網(wǎng)頁制作以及卓尼網(wǎng)絡(luò)營(yíng)銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，卓尼網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到卓尼省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

首先，系統(tǒng)是什么？根據(jù)《系統(tǒng)架構(gòu)》一書的定義，系統(tǒng)是由一組實(shí)體和這些實(shí)體之間的關(guān)系所構(gòu)成的集合，其功能要大于這些實(shí)體各自的功能之和。對(duì)于我們的場(chǎng)景，系統(tǒng)可能是 App、Web 應(yīng)用、服務(wù)、批處理程序等，也可能是包括所有這些的一個(gè)大系統(tǒng)。

隨著互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)的結(jié)合越來越深入，業(yè)務(wù)會(huì)越來越復(fù)雜。我們?cè)撊绾卧O(shè)計(jì)我們的系統(tǒng)呢？

從產(chǎn)品到研發(fā)

從產(chǎn)品作出原型，到研發(fā)編程實(shí)現(xiàn)，中間有巨大的鴻溝。越復(fù)雜的業(yè)務(wù)需求，這條鴻溝就越大。一般而言，我們至少還要有兩個(gè)步驟：業(yè)務(wù)分析與架構(gòu)設(shè)計(jì)。

業(yè)務(wù)分析，主要處理的是業(yè)務(wù)領(lǐng)域的建模。解決的問題是業(yè)務(wù)上如何實(shí)現(xiàn)。然后是技術(shù)與架構(gòu)方面的設(shè)計(jì)，主要針對(duì)的是技術(shù)實(shí)現(xiàn)，解決的問題是技術(shù)上如何實(shí)現(xiàn)。這兩個(gè)方面是會(huì)互相影響的，設(shè)計(jì)的時(shí)候往往需要來來回回的考慮這兩個(gè)方面。甚至系統(tǒng)開發(fā)時(shí)也時(shí)常會(huì)需要調(diào)整模型或者架構(gòu)，當(dāng)然相應(yīng)的也需要更新文檔。

基本原則

設(shè)計(jì)與分析的過程就是不停的進(jìn)行抽象和封裝，并且確定各個(gè)系統(tǒng)實(shí)體的細(xì)節(jié)。抽象是指將業(yè)務(wù)抽象為軟件領(lǐng)域的元素（系統(tǒng)、模塊或類）；封裝則是指定義元素的邊界，隱藏實(shí)現(xiàn)，開放接口。

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

業(yè)務(wù)分析

分析方法

業(yè)務(wù)分析是針對(duì)業(yè)務(wù)領(lǐng)域的建模，產(chǎn)出就是分析模型。分析模型描述系統(tǒng)的邏輯設(shè)計(jì)與結(jié)構(gòu)，一般會(huì)包括需求用例、實(shí)體模型以及業(yè)務(wù)場(chǎng)景的交互流程、狀態(tài)轉(zhuǎn)換等。分析模型讓非技術(shù)人員能夠理解系統(tǒng)是如何構(gòu)造的，讓技術(shù)人員能夠以此為基礎(chǔ)搭建系統(tǒng)。

分析的過程是不斷迭代的。特別對(duì)于復(fù)雜的、涉及多個(gè)業(yè)務(wù)領(lǐng)域的需求，第一步往往需要在整體系統(tǒng)的層級(jí)進(jìn)行分析，然后將模型劃分到多個(gè)子系統(tǒng)，然后再在子系統(tǒng)的層級(jí)進(jìn)行更細(xì)節(jié)的分析與建模。

另一方面，分析過程中需要不斷的優(yōu)化和調(diào)整。例如在確定實(shí)體的行為細(xì)節(jié)時(shí)，發(fā)現(xiàn)兩個(gè)實(shí)體的耦合很高，那么可能需要重新進(jìn)行抽象，調(diào)整實(shí)體的功能范圍。

理清業(yè)務(wù)需求

理清業(yè)務(wù)需求是所有分析與設(shè)計(jì)的前提：

確定系統(tǒng)的利益相關(guān)者（Stakeholder）及他們的關(guān)注點(diǎn)。
確定系統(tǒng)的業(yè)務(wù)需求，即「誰」使用該系統(tǒng)「做什么」。
確定系統(tǒng)的功能范圍，即該系統(tǒng)「包含什么」，不包含「什么」。

系統(tǒng)需要滿足利益相關(guān)者的關(guān)注點(diǎn)，所以要確保所有這些關(guān)注點(diǎn)都有涉及到。最重要的利益相關(guān)者當(dāng)然就是用戶（有時(shí)還會(huì)細(xì)分為不同類型的用戶），此外還應(yīng)該包括供應(yīng)商、合作方、運(yùn)營(yíng)、銷售、老板甚至政府等等，也同樣包括研發(fā)測(cè)試和運(yùn)維。

具體到系統(tǒng)的用戶，還需要細(xì)分到角色，即使有些角色實(shí)際可能是同一個(gè)人。比如對(duì)于門診，可能有護(hù)士、顧問或系統(tǒng)管理員等等，可以進(jìn)行不同的操作。需求范圍簡(jiǎn)單話用一個(gè)列表即可，復(fù)雜的系統(tǒng)可以考慮使用用例圖。

例如，門診預(yù)約系統(tǒng)的用例圖可以這樣畫：

角色有醫(yī)生、患者和門診員工。
用例有設(shè)置排班、管理預(yù)約以及預(yù)約/取消醫(yī)生。

建立實(shí)體模型

實(shí)體模型是確定系統(tǒng)包含的實(shí)體以及它們之間的關(guān)聯(lián)的過程：

理清業(yè)務(wù)概念，統(tǒng)一業(yè)務(wù)詞匯。
抽象業(yè)務(wù)實(shí)體，包括事件、人/角色、地點(diǎn)和事物等。
識(shí)別實(shí)體關(guān)系：繼承、聚合、關(guān)聯(lián)等。

實(shí)體模型也叫 ER（Entity-Relation）模型?？梢钥紤]使用四色法建模，一般可以使用類圖或組件圖表示。需要注意的是一定要理清業(yè)務(wù)的概念，統(tǒng)一命名和定義業(yè)務(wù)相關(guān)詞匯，這是進(jìn)一步溝通的基礎(chǔ)。

例如，預(yù)約系統(tǒng)的實(shí)體關(guān)系圖可以這樣畫：

分析業(yè)務(wù)場(chǎng)景

場(chǎng)景分析用于確定具體業(yè)務(wù)場(chǎng)景中，各個(gè)參與者的交互過程，從而進(jìn)一步完善分析模型：

分析具體業(yè)務(wù)場(chǎng)景，確定業(yè)務(wù)規(guī)則，梳理業(yè)務(wù)流程。
如果涉及復(fù)雜的狀態(tài)轉(zhuǎn)換，需要確定狀態(tài)轉(zhuǎn)換邏輯。
補(bǔ)充和完善實(shí)體模型的內(nèi)容描述。

對(duì)于一個(gè)業(yè)務(wù)場(chǎng)景，參與者可能包括人、內(nèi)部模塊、外部服務(wù)等，這一步需要理清楚整個(gè)業(yè)務(wù)過程和規(guī)則。需要注意的是，對(duì)于一些次要路徑或者異常路徑，也一定要考慮到。對(duì)于業(yè)務(wù)過程和規(guī)則，可以使用普通的流程圖、泳道圖，也可以考慮UML的活動(dòng)圖，狀態(tài)轉(zhuǎn)換過程則可以通過UML的狀態(tài)圖展示。

對(duì)于場(chǎng)景分析中不太確定的需求，或者可能會(huì)有技術(shù)難點(diǎn)地方，可以記錄下來，后面確認(rèn)和驗(yàn)證。

例如，下面是預(yù)約系統(tǒng)的預(yù)約狀態(tài)圖。

例如，下面是我們和一家藥品供應(yīng)商對(duì)接的流程圖。

架構(gòu)與技術(shù)設(shè)計(jì)

架構(gòu)方法

架構(gòu)設(shè)計(jì)不一定要深入到具體的實(shí)現(xiàn)細(xì)節(jié)，但是應(yīng)該盡量全面的考慮系統(tǒng)的各個(gè)方面。關(guān)鍵是要對(duì)項(xiàng)目風(fēng)險(xiǎn)有比較大的把握，這樣才能避免開發(fā)過程出現(xiàn)不可控的問題。具體設(shè)計(jì)需要多詳細(xì)，是需要設(shè)計(jì)者自己去把握度的。

對(duì)于暫時(shí)無法確定的內(nèi)容，應(yīng)該在文檔中注明，在開發(fā)過程早期進(jìn)行試驗(yàn)和驗(yàn)證。如果對(duì)項(xiàng)目比較關(guān)鍵，可以考慮先行開發(fā)原型來進(jìn)行驗(yàn)證。

架構(gòu)設(shè)計(jì)常見的是4+1視圖，即邏輯視圖、開發(fā)視圖、過程視圖、物理視圖，再加上場(chǎng)景。另外一種我更喜歡的是視點(diǎn)和視角的方法，如果再加上場(chǎng)景的話，可能會(huì)更全面。

確定整體架構(gòu)

首先需要在整體上考慮系統(tǒng)的位置和職責(zé)：

確定系統(tǒng)在整個(gè)上下文中的位置，與其他系統(tǒng)的關(guān)聯(lián)。
確定系統(tǒng)自身以及各個(gè)外部系統(tǒng)的職責(zé)。

整體架構(gòu)對(duì)應(yīng)的就是情景視圖。這一步將系統(tǒng)看作一個(gè)黑盒，確認(rèn)系統(tǒng)自己的范圍和職責(zé)，相關(guān)的外部系統(tǒng)的職責(zé)，以及他們之間的關(guān)聯(lián)。

例如，交易系統(tǒng)的整體架構(gòu)大概是這樣的：

設(shè)計(jì)功能模塊

其次需要確定系統(tǒng)內(nèi)部的功能模塊及其職責(zé)：

確定系統(tǒng)的模塊劃分。
確定每個(gè)模塊的職責(zé)以及模塊間的關(guān)聯(lián)。

功能模塊對(duì)應(yīng)的就是功能視圖。這一步需要明確系統(tǒng)的內(nèi)部結(jié)構(gòu)。內(nèi)部模塊劃分主要有基于業(yè)務(wù)功能的劃分，以及基于實(shí)現(xiàn)層次的劃分，稍復(fù)雜的系統(tǒng)可能會(huì)兩者都有。也有一些系統(tǒng)會(huì)采用CQRS等架構(gòu)，那么模塊劃分可能會(huì)不一樣。功能模塊可以使用UML的組件圖表示。

明確架構(gòu)關(guān)注點(diǎn)

然后需要確定系統(tǒng)架構(gòu)的理念：

理清架構(gòu)設(shè)計(jì)需要考慮的關(guān)注點(diǎn)。
確定系統(tǒng)的架構(gòu)設(shè)計(jì)上的取舍。

這一步需要考慮各種架構(gòu)視角，主要有(但不限于)以下關(guān)注點(diǎn)：

安全性：身份驗(yàn)證、權(quán)限控制和授權(quán)、操作日志、安全審計(jì)、數(shù)據(jù)一致性等。
性能：響應(yīng)時(shí)間、吞吐量等。
穩(wěn)定性：停機(jī)時(shí)間、故障恢復(fù)、數(shù)據(jù)一致性、數(shù)據(jù)備份等。
擴(kuò)展性：未來可能的變更，以及如何應(yīng)對(duì)變更。
其他：國(guó)際化、易用性、合規(guī)性等。

以上所有的關(guān)注點(diǎn)，和開發(fā)資源、時(shí)間、范圍各個(gè)方面，往往很難同時(shí)滿足，所以必須要明確哪些是關(guān)注的重點(diǎn)，哪些則可以有所妥協(xié)。例如，為了滿足性能要求，可能需要降低數(shù)據(jù)的一致性；為了合規(guī)性，可能不得不花更多開發(fā)時(shí)間。

對(duì)于未來可能的變更，也一定要考慮到。通常情況下，我們至少要考慮未來半年的架構(gòu)，但可能只實(shí)現(xiàn)當(dāng)前需要的版本，但是確保未來可以很容易的擴(kuò)展。

一旦確定了關(guān)注的重點(diǎn)，在設(shè)計(jì)和開發(fā)的每個(gè)過程中，我們都要把這個(gè)重點(diǎn)放在心上。

例如，對(duì)于訂單系統(tǒng)，因?yàn)樯婕暗藉X和交易，數(shù)據(jù)的一致性和可追溯性極其重要。下單和支付的API都必須是冪等的，每一筆收入變動(dòng)都必須記錄日志，必須有嚴(yán)格的核對(duì)和對(duì)賬。為了安全，每一次API調(diào)用都必須進(jìn)行權(quán)限驗(yàn)證。

例如，亞馬遜有個(gè)知名的原則，所有的系統(tǒng)間調(diào)用都必須通過定義清楚的 API，不允許共享數(shù)據(jù)庫。這也是一個(gè)架構(gòu)原則。

設(shè)計(jì)數(shù)據(jù)庫模型

如果分析時(shí)有了完善了實(shí)體模型，設(shè)計(jì)數(shù)據(jù)庫模型就不是什么難事了。開發(fā)完成后，數(shù)據(jù)庫模型應(yīng)該以數(shù)據(jù)庫為準(zhǔn)，架構(gòu)文檔就不需要保留這一部分了。

需要注意的是，數(shù)據(jù)庫模型是實(shí)體模型在關(guān)系數(shù)據(jù)庫的實(shí)現(xiàn)，但不一定是嚴(yán)格的映射。數(shù)據(jù)庫可能會(huì)有范式、冗余、一致性、同步、分表分庫方面的考慮，必要時(shí)可能會(huì)使用非關(guān)系型數(shù)據(jù)庫如ElasticSearch、Cassandra等。

有時(shí)候還會(huì)涉及到數(shù)據(jù)處理的流程。例如，一張圖片提交后可能需要進(jìn)行預(yù)處理，然后有運(yùn)營(yíng)人員進(jìn)行審核和標(biāo)記，最后進(jìn)行發(fā)布。過程中數(shù)據(jù)的保存形式或者狀態(tài)標(biāo)記可能是不一樣的。

數(shù)據(jù)庫設(shè)計(jì)的更多規(guī)范可以參考數(shù)據(jù)庫規(guī)范。

設(shè)計(jì)接口

然后就需要確定 API 細(xì)節(jié)了。一般我們的服務(wù)的 API 是 JSON 格式 HTTP 形式的請(qǐng)求和回調(diào)。API 可能是接口定義，也可能會(huì)有其他接口形式，例如消息隊(duì)列等。設(shè)計(jì)階段，API 文檔可以通過 Markdown 文檔、RAP 等記錄，開發(fā)完成后可以獨(dú)立維護(hù)，或者使用 Swagger 和代碼一起維護(hù)。

接口設(shè)計(jì)需要注意幾點(diǎn)：

接口的設(shè)計(jì)應(yīng)該以系統(tǒng)提供的領(lǐng)域資源或服務(wù)為基礎(chǔ)，同時(shí)考慮調(diào)用方的需求。
接口的粒度很重要，太細(xì)則調(diào)用方很不方便需要多次調(diào)用，太粗則無法靈活的滿足各種需求，需要仔細(xì)權(quán)衡。
接口的設(shè)計(jì)也需要從調(diào)用方的角度考慮如何進(jìn)行調(diào)用。必要的話可以畫流程圖、時(shí)序圖、狀態(tài)圖詳細(xì)說明調(diào)用順序即狀態(tài)轉(zhuǎn)換等。
接口的文檔一定要清楚的說明調(diào)用接口的方法、前置條件，參數(shù)作用、不同條件的處理、返回接口等。

場(chǎng)景實(shí)現(xiàn)

一般情況下，有了業(yè)務(wù)場(chǎng)景分析，有了數(shù)據(jù)庫模型和 API，系統(tǒng)的實(shí)現(xiàn)一般是比較簡(jiǎn)單了。但可能還會(huì)有一些細(xì)節(jié)需要進(jìn)一步考慮實(shí)現(xiàn)細(xì)節(jié)，以避免風(fēng)險(xiǎn)?？梢钥紤]更細(xì)節(jié)的活動(dòng)圖、時(shí)序圖甚至偽代碼。例如：

復(fù)雜業(yè)務(wù)場(chǎng)景的詳細(xì)設(shè)計(jì)，或者復(fù)雜算法的實(shí)現(xiàn)描述。
離線任務(wù)的執(zhí)行方式、時(shí)間和步驟。
非業(yè)務(wù)的一些場(chǎng)景，例如網(wǎng)絡(luò)斷開、緩存失效、第三方系統(tǒng)宕機(jī)等。

例如，對(duì)于支付系統(tǒng)的微信 Web 支付過程，涉及系統(tǒng)較多，交互比較復(fù)雜，可以通過時(shí)序圖來定義清楚：

其他考慮

對(duì)于我們的后臺(tái)系統(tǒng)來說，基本的技術(shù)框架都已確定，可以解決很多基礎(chǔ)的非業(yè)務(wù)需求。不過設(shè)計(jì)系統(tǒng)時(shí)，也還是需要考慮以下等方面：

通用處理的方式，例如日志、錯(cuò)誤處理、代碼規(guī)范、單元測(cè)試等。
數(shù)據(jù)遷移、同步和回滾方案：對(duì)于老系統(tǒng)的重構(gòu)，需要仔細(xì)考慮并且提前演練。
系統(tǒng)部署和發(fā)布：如果系統(tǒng)涉及多個(gè)子系統(tǒng)，需要考慮系統(tǒng)的部署架構(gòu)。特別是同時(shí)涉及到數(shù)據(jù)遷移的，一定要仔細(xì)考慮發(fā)布的過程。
系統(tǒng)監(jiān)控和告警：除了常規(guī)的監(jiān)控和告警，是否有特殊的指標(biāo)需要監(jiān)控？
并發(fā)和數(shù)據(jù)量：如果系統(tǒng)可能面臨對(duì)高并發(fā)和大數(shù)據(jù)量的問題， 需要設(shè)計(jì)對(duì)應(yīng)的方案，以及相關(guān)的性能測(cè)試和壓力測(cè)試。
緩存設(shè)計(jì)：如果需要使用緩存，除了要考慮緩存的選型、方案，而且要把緩存放到整個(gè)系統(tǒng)中去進(jìn)行設(shè)計(jì)。
技術(shù)選型：涉及到新技術(shù)的引入時(shí)，則需要仔細(xì)分析備用技術(shù)的優(yōu)缺點(diǎn)，選擇最合適的方案。

設(shè)計(jì)方法和工具

UML
面向?qū)ο笤O(shè)計(jì)（OOAP）
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）
CQRS & Event Sourcing

參考書

分析模式：可復(fù)用的對(duì)象模型( https://book.douban.com/subject/4832380/ )
軟件系統(tǒng)架構(gòu)：使用視點(diǎn)和視角與利益相關(guān)者合作( https://book.douban.com/subject/24530471/ )
UML和模式應(yīng)用( https://book.douban.com/subject/1792387/ )
架構(gòu)即未來：現(xiàn)代企業(yè)可擴(kuò)展的Web架構(gòu)、流程和組織( https://book.douban.com/subject/26765979/ )

文章

從用例分析到方案評(píng)審，我們是如何進(jìn)行業(yè)務(wù)系統(tǒng)設(shè)計(jì)的( http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg )
互聯(lián)網(wǎng)公司研發(fā)RD如何撰寫總體設(shè)計(jì)與詳細(xì)設(shè)計(jì)文檔( http://www.10tiao.com/html/249/201412/201657741/1.html )
用UML做好系統(tǒng)分析( http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis )
運(yùn)用四色建模法進(jìn)行領(lǐng)域分析( http://www.infoq.com/cn/articles/xh-four-color-modeling )
從“四色建模法”到“限界紙筆建模法”( http://insights.thoughtworkers.org/paper-pen-modeling/ )
淺談我對(duì)DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的理解( http://www.cnblogs.com/netfocus/p/5548025.html )
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)參考架構(gòu)詳解( http://blog.csdn.net/bluishglc/article/details/6681253 )
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)和實(shí)踐( http://www.infoq.com/cn/articles/cjq-ddd )
我對(duì)CQRS/EventSourcing架構(gòu)的思考( http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027 )
架構(gòu)設(shè)計(jì)基礎(chǔ)知識(shí)整理( https://blog.dreamtobe.cn/2016/03/09/oo_architecture/ )

作者：章燁明，杏仁醫(yī)生CTO。中老年程序員，關(guān)注各種技術(shù)和團(tuán)隊(duì)管理。
出處： https://mp.weixin.qq.com/s/JoKzg2vUe2IwX099xSFtFA

網(wǎng)頁題目：如何進(jìn)行系統(tǒng)分析與設(shè)計(jì)-創(chuàng)新互聯(lián)
分享路徑：http://m.rwnh.cn/article12/cescgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、建站公司、虛擬主機(jī)、小程序開發(fā)、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)