• 1. 軟體架構體系
  • 1.1. 系統與子系統
  • 1.2. 模塊、組件、服務
  • 1.3. 軟體架構體系
• 2. 架構原則
  • 2.1. 解耦
  • 2.2. 分層
  • 2.3. 封裝
• 3. 架構的方法
  • 3.1 業務架構
  • 3.2 功能架構
  • 3.3 系統架構
  • 3.4 技術架構
  • 3.5 資料架構
  • 3.6 部署架構
• 4. 架構演進之路
  • 4.1. 單體架構
  • 4.2. 分布式架構
    • 4.2.1 應用集群
    • 4.2.2 分布式快取
    • 4.3.3 業務拆分
    • 4.3.4 分庫分表和讀寫分離
    • 4.3.5 靜態化和CDN
    • 4.3.6 異步解耦
  • 4.3. 微服務架構
• 5. 服務化
  • 5.1 為什么需要服務化
  • 5.2 服務化的好處
  • 5.3 服務化的問題
• 6. 常見的需求問題
  • 6.1. 需求不明確
  • 6.2. 需求理解不一致
  • 6.3. 需求自身經常變動
• 7. 需求獲取
  • 7.1 需求來源
  • 7.2 需求分類
  • 7.3 獲取步驟
• 8. 需求要素
  • 8.1 角色、場景
  • 8.2 業務流程
  • 8.3 資料物體
  • 8.4 功能性需求
  • 8.5 非功能性需求
• 9. 案例：電商訂單系統
  • 9.1 概述
  • 9.2 角色
  • 9.3 場景(用例)
  • 9.4 功能
  • 9.5 物體
  • 9.6 流程

• 能夠掌握系統、子系統、模塊、組件、服務、框架、架構等概念的含義
• 能夠知道單體架構、分布式架構、微服務架構的適用場景、優勢和劣勢
• 能夠知道微服務架構常見技術框架
• 能夠了解組件化、服務化產生的原因、優勢和問題，初步具備中臺概念
• 了解常見的需求問題
• 掌握一個需求包含的要素
• 掌握如何做需求分析

1. 軟體架構體系

1.1. 系統與子系統

系統：泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的作業的群體，

• 關聯：系統是由一群有關聯的個體組成的，沒有關聯的個體堆在一起不能成為一個系統，例如，把一個汽車發動機和一堆蘋果放在一起不能稱之為一個系統，把發動機、底盤、輪胎、車架組合起來才能成為一臺汽車，構成一個系統，
• 規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自為政，規則規定了系統內個體分工和協作的方式，例如，汽車發動機負責產生動力，然后通過變速器和傳動軸，將動力輸出到車輪上，從而驅動汽車前進，
• 能力：系統能力與個體能力有本質的差別，系統能力不是個體能力之和，而是產生了新的能力，例如，汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力，

子系統：子系統也是由一群有關聯的個體所組成的系統，多半會是更大系統中的一部分， 子系統的定義和系統定義是一樣的，只是觀察的角度有差異，一個系統可能是另外一個更大系統的子系統，

以微信為例來做一個分析：

• 微信本身是一個系統，包含聊天、登錄、支付、朋友圈等子系統，
• 朋友圈這個系統又包括動態、評論、點贊等子系統，
• 評論這個系統可能又包括防刷子系統、審核子系統、發布子系統、存盤子系統，
• 評論審核子系統不再包含業務意義上的子系統，而是包括各個模塊或者組件，這些模塊或者組件本身也是另外一個維度上的系統，例如，MySQL、Redis 等是存盤系統，但不是業務子系統

1.2. 模塊、組件、服務

• 模塊：是一套一致而互相有緊密關連的軟體組織，它分別包含了程式和資料結構兩部分，現代軟體開發往往使用模塊作為合成的單位
• 組件：自包含的、可編程的、可重用的、與語言無關的軟體單元，組件可以很容易被用于組裝應用程式中

模塊和組件都是系統的組成部分，只是從不同的角度拆分系統而已，例如：

• 從邏輯的角度來拆分系統后，得到的單元就是“模塊”；從物理的角度來拆分系統后，得到的單元就是“組件”，
• 劃分模塊的主要目的是職責分離；劃分組件的主要目的是單元復用，

例如我們要做一個學生資訊管理系統，這個系統從邏輯的角度來拆分，可以分為：登錄注冊模塊、個人資訊模塊、個人成績模塊；從物理的角度來拆分，可以拆分為應用程式、 Nginx、Web 服務器、MySQL等

• 服務：服務和組件有某種相似之處：它們都將被外部的應用程式使用，兩者之間最大的差異在于：組件是在本地使用的（例如Jar檔案）；而服務是運行起來的，要通過同步或異步的遠程介面來遠程使用（例如RESTFul介面、web service、訊息系統、RPC，或者socket）

服務是可以單獨運行，并且對外提供功能的一種形式，可以將一個復雜的專案分解成多個服務，當某一個服務掛掉時不會拖垮整個系統，如果沒有服務化，每當一個新的功能被添加到系統中就會影響到所有功能；如果采取服務化，每個服務只對其上下游的服務負責，

1.3. 軟體架構體系

2. 架構原則

2.1. 解耦

在軟體工程中，耦合指的就是物件之間的依賴性，物件之間的耦合度越高，維護成本越高，因此物件的設計應使類和構件之間的耦合最小，軟體設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準，劃分模塊的一個準則就是高內聚低耦合，

耦合性存在于各個領域，而非軟體設計中獨有的，理論上說絕對的零耦合是做不到的，但可以通過一些方法將耦合降至最低，降低耦合度即可理解為解耦，在設計上解耦的核心思想是【彼此獨立，互不依賴】，

2.2. 分層

分層結構是最為流行、應用最廣泛的應用軟體的設計方式，在應用了分層結構的系統中，各個子系統按照層次的形式組織起來，上層使用下層的各種服務，而下層對上層一無所知，每一層都對自己的上層隱藏其下層的細節，

經典三層架構：

在軟體架構中，經典三層架構自頂向下由用戶界面層、業務邏輯層、資料訪問層組成，在提出該分層架構的時代，多數系統往往較為簡單，本質上都是一個單體架構的資料庫管理系統，這種分層架構有效地隔離了業務邏輯與資料訪問邏輯，使得這兩個不同關注點能夠相對自由和獨立地演化，經典的三層架構如下所示：

分層的設計原則是：保證同一層的組件處于同一個抽象層次，即所謂的“單一抽象層次原則”，這一原則可以運用到分層架構中，比如下圖所示：

2.3. 封裝

假設我們有一個程式，它在邏輯上有一些不同的物件，并且這些物件彼此之間會相互交流，

在一個類中，當每個物件的狀態保持相對孤立，就實作了封裝，其余的物件并不能觀察到這個物件的狀態，他們能做到的只有呼叫一些被稱作“方法”的通用功能，

因此，物件使用方法掌控著自己的狀態，除非明確允許，沒有其他人可以接觸到它，如果你想和某個物件交流，你需要使用提供的方法，但在默認情況下，你無法改變物件的狀態，

3. 架構的方法

架構圖是為了表示軟體系統的整體輪廓和各個組件之間的相互關系和約束邊界，以及軟體系統的物理部署和軟體系統的演進方向的整體視圖，要讓干系人理解、遵循架構決策，就需要把架構資訊傳遞出去，架構圖就是一個很好的載體，不同的視角和角色，關注點也是不同的，看到的架構圖是不一樣的，

3.1 業務架構

使用者：CEO、CIO、CTO、產品總監

核心業務流程：

核心能力:

3.2 功能架構

使用者：產品總監、產品經理

示例：黑馬頭條功能架構圖

3.3 系統架構

使用者：系統架構師

3.4 技術架構

使用者：系統架構師

示例一：https://www.processon.com/view/link/636059870791295cf8db8006

示例二：冷鏈專案技術架構圖

3.5 資料架構

使用者：CTO、系統架構師、資料架構師

示例一：資料模型

示例二：大資料平臺架構

3.6 部署架構

使用者：運維架構師

示例一：https://www.processon.com/view/link/63648dfd637689059c421af8

示例二：冷鏈專案部署架構圖

4. 架構演進之路

4.1. 單體架構

公司發展的初期，資金少、用戶少，需要的軟體產品的資料和并發量都比較小，這個時期大多數的軟體系統只需要單一服務器就可以滿足需求，所有的業務邏輯都在單一應用系統，單應用、單資料庫，資料庫部署在和應用相同的虛擬機或服務器上，或者放置在另外一臺機器上，此時的架構圖如下：

或

• 作業系統：windows、linux
• 應用服務器：tomcat、jetty、jboos、apache、weblogic、websphere...
• 資料庫：mysql、oracle、db2...
• 應用系統：可以用java、php、asp等各種語言開發

這種架構模式優點很明顯：

• 節省服務器資源，投入少
• 管理簡單：上線、部署、監控、問題排查等都比較簡單
• 開發簡單：軟體系統功能整合在一起，不需要考慮太多服務依賴等問題，代碼管理也比較簡單明了，
• 測驗簡單

隨著公司和業務進入快速發展時期，軟體系統面臨來自多方面的考驗：

單體架構的缺點也越發的凸顯出來：

• 可用性差： 應用和資料庫都是單點，無論應用還是資料庫出現問題，整個系統的就會不可用了
• 穩定性差： 系統耦合度高，新增或者修改任何一個功能，哪怕只是一行代碼，也需要重啟服務器，此時系統是不可用的
• 性能差：單一的應用服務器和資料庫服務器，性能總會有上限的，當用戶變多或者準確的說相同時刻并發訪問多時，系統就容易掛掉了

4.2. 分布式架構

單體架構有著明顯的缺陷，隨著系統訪問量的增多，這些缺陷越來越凸顯，為了解決這些缺陷，架構升級了，變成了分布式架構，分布式，就是多個實體提供服務，下面我們來簡單介紹下常見的一些解決方案，

4.2.1 應用集群

• 反向代理服務器：把用戶請求反向路由到應用服務器，常見的反向代理服務器是Nginx或HAProxy
• 應用服務器：集群化部署
• 資料庫服務器：主從部署

架構優點：

• 可用性高：代理服務器、應用服務器、資料庫服務器都是做了集群，當某臺機器掛掉后，其他機器能夠幾乎無感的接替下任務
• 性能比單體架構高： 用戶的請求分發到多個應用服務器上，整體性能接近單體結構的三倍
• 安全性高： 外網用戶訪問的是反向代理服務器，應用和資料庫隔離在內網中

4.2.2 分布式快取

快取分為多級快取，比如本地快取（JVM中），分布式快取服務器（Redis集群等），本地快取的訪問速度更快一些，但是受應用服務器記憶體限制，其快取資料量有限，而且會出現和應用程式爭用記憶體的情況，遠程分布式快取可以使用集群的方式，部署大記憶體的服務器作為專門的快取服務器，可以在理論上做到不受記憶體容量限制的快取服務，常見快取服務器包括Redis、Memcached等，使用快取后，資料訪問壓力得到有效緩解，

4.3.3 業務拆分

業務進一步發展，用戶越來越多，系統又出現了瓶頸，此時整個電商系統可以做系統拆分了，系統拆分分為水平拆分和垂直拆分，

水平拆分：

拆分成商品、訂單、交易、用戶、支付等多個系統，每個系統都都是多臺服務器構成的集群，

垂直拆分：

將一些公共業務和服務，如用戶中心拆分成注冊登錄中心和用戶中心，短信、檔案、訊息等各種公共服務，從業務系統中拆分剝離出來，

這種架構的優勢也比較明顯，一方面，應用系統增加了，能夠回應用戶的請求也會變多，另一方面公共服務能夠提供給所有的應用使用，達到服務復用的效果，但是大家需要注意的是資料庫有可能只是一個，而單一資料庫服務器的處理能力必然是有限的，隨著用戶并發量的持續增多，資料庫將會是系統的瓶頸，

4.3.4 分庫分表和讀寫分離

讀寫分離：

在網站的用戶達到一定規模后，資料庫因為負載壓力過高而成為網站的瓶頸，目前大部分的主流資料庫都提供主從熱備功能，通過配置資料庫的主從關系，可以將一臺資料庫服務器的資料更新同步到另外的資料庫服務器上，網站利用資料庫的這一功能，實作資料庫讀寫分離，從而改善資料庫負載壓力，

應用服務器在寫資料的時候，訪問主資料庫，主資料庫通過主從復制機制將資料更新同步到從資料庫，這樣當應用服務器讀資料的時候，就可以通過從資料庫獲得資料，

分庫分表：

隨著資料庫中的資料量越來越大，相應的，查詢所需要的時間也越來越多，這個時候，相當于資料的處理遇到了瓶頸，另一方面單庫發生意外的時候，需要修復的是所有的資料，而多庫中的一個庫發生意外的時候，只需要修復一個庫，基于此，分庫分表就成了必然，分庫分表的策略很多，如按照用戶、訂單、交易、商品等進行分庫，不同的資料庫中按照時間進行分表，

分庫分表帶來性能上的顯著提升，但相應的管理和維護成本也比較高，比如資料庫服務器的維護、分表策略的維護，為了便于應用程式訪問分庫分表、讀寫分離后的資料庫，通常在應用服務器端使用專門的資料訪問模塊，使資料庫的分庫分表和讀寫分離對應用透明，

4.3.5 靜態化和CDN

隨著網站業務不斷發展，用戶規模越來越大，和中國復雜的網路環境，不同地區的用戶訪問網站時，速度差別也極大，為了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度，主要手段有使用頁面的靜態化和CDN，

操作方式上把一些頁面，比如某些商品的詳情資訊，在發布商品時將頁面靜態化，靜態化頁面和靜態資源可以放在CDN服務器，部署在網路服務提供商的機房，用戶在訪問靜態資源時，可以很好的利用CDN的優點，從距離自己最近的網路提供商機房獲取資料，

4.3.6 異步解耦

應用之間的服務存在互相呼叫的情況，但有些場景下，并不需要同步呼叫，比如某個業務完成后，需要短信通知對方，而短信接收的時間晚幾秒鐘都是可以接受的，此時就不需要同步處理了，我們可以使用訊息佇列，把發送短信的內容扔到訊息佇列中，達到異步處理的效果，從而增強業務系統的性能，此時對于服務之間也達到了解耦的功能，服務之間的依賴減少了，

4.3. 微服務架構

微服務架構是分布式架構的深化，分布式架構偏向于部署和環境，比如上邊提到的應用、資料庫、快取等，在多臺機器上進行部署，就屬于分布式，微服務架構通過業務拆分實作服務組件化，通過組件組合快速開發系統，業務單一的服務組件又可以獨立部署，使得整個系統變得清晰靈活，

大量的分布式服務又使得架構實作面臨問題，如服務注冊發現，服務統一接入和權限控制，服務的負載均衡，服務配置的集中管理，服務熔斷，服務監控等，

所以微服務架構是由這些基礎的服務組件和業務微服務組件共同組成：

• 服務注冊發現組件： 進行服務治理
• 服務網關組件：提供統一入口和權限控制
• 負載均衡組件：提供客戶端或服務器端的負載均衡
• 集中配置組件：提供服務集中管理
• 熔斷器組件：提供服務熔斷
• 服務追蹤組件：提供服務監控

采用微服務架構后，專案可以快速迭代與持續交付，但是也帶了一些弊端，開發人員除了需要關注業務邏輯實作外還需要考慮業務的一系列問題，比如服務注冊，服務發現，服務通訊，負載均衡，服務熔斷，服務超時等，這些是非常重要的，大多數時候，我們需要依賴第三方庫或者組件來提供這些服務，例如Hystrix，Eureka、Zookeeper等組件，在其服務組織中起到了廣泛的應用，

5. 服務化

5.1 為什么需要服務化

傳統企業或者很多企業的軟體，大多不止一套系統，都是各個獨立大系統的堆砌，整體存在的問題是：

• 擴展性差
• 可靠性不高
• 維護成本還很大
• 重復輪子很多

非常容易能夠想到，解決這些問題的方法是：組件化、服務化，

微服務架構，將各個組件或者模塊分散到各個服務中，對整個系統實作解耦，那微服務架構強調的重中之重就是業務系統需要完善的組件化和服務化，什么是組件化？

組件化，即將一個大系統，按照一定的業務或者技術維度，拆分成獨立的組件，目的是為了分而治之，為了可重用，為了減少耦合度，比如按照技術維度：檔案上傳下載組件、短信發送組件、搜索組件、快取組件；按照業務維度：用戶中心、商品中心、支付中心等，

阿里巴巴提出 大中臺，小前臺戰略，就是把組件化、插件化、服務化解決方案到極致，通過產品線公共業務或者技術下沉，形成各種技術中臺或者業務中臺，

5.2 服務化的好處

• 呼叫簡單
• 代碼復用
• 業務隔離
• 資料庫解耦

5.3 服務化的問題

有利必有弊，服務化也會面臨很多問題：

• 本身不大的系統，業務不復雜的系統也不需要微服務架構
• 多個模塊資料庫，分布式事務是一個挑戰
• 增加了測驗、運維等事務的復雜性

6. 常見的需求問題

6.1. 需求不明確

• 盲人摸象，各階段人員只掌握了一段
• 初期階段，業務還在摸索
• 各部門目標和kpi不一致，需求有沖突

6.2. 需求理解不一致

客戶：我家有三個小孩，我須要一個能三個人用的秋千，它是由一繩子吊在我園子里的樹上，

專案經理：秋千這東西太簡單了，就是一塊板子，兩邊用繩子吊起來，掛在樹上的兩個枝子上，

設計師：這個無知的專案經理，兩個樹枝上掛上秋千哪還能蕩漾起來嗎？除非是把樹從中截斷再支起來，這樣就滿足要求了，

專案最重要的階段是進行需求分析，明白真正的需求，專案需求指的是用戶真正需要什么，而不是供應商假設用戶需要什么和供應商能夠供應什么，需求的準確定位就是要按用戶要求，對目標系統提出完整、準確、清晰、具體要求，這對一個專案的成功來說非常重要，需求分析做得不好，就會造成需求不斷變更，從而影響進度、費用，甚至會導致專案失敗，

6.3. 需求自身經常變動

• 盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟體的核心建筑在穩定的需求上，否則將會吃盡苦頭，
• 在合同中一定要說清楚“做什么”和“不做什么”，如果合同含含糊糊，日后扯皮的事情就多，

7. 需求獲取

7.1 需求來源

干系人

干系人（Stake holder）：對于系統有利益關系的個人，團隊、組織和其他系統，

專案干系人包括但不限于：

• 投資方：系統的投資方
• 主管方：批準/管理系統的
• 最終用戶：用戶/系統受益方
• 操作方：操作/維護系統的
• 監管方：認證系統的
• 測驗方：負責系統驗收

示例：XX信貸管理系統

投資方：     資金部
主管方：  	 資訊化部
用戶代表：   市場部
最終用戶：   營業員
監管方：     審計部
測驗方：     資訊化部
操作方：     資訊化部

7.2 需求分類

軟體需求的三個層次：

1. 業務需求

描述組織或客戶的高層次目標，通常問題定義本身就是業務需求，業務需求就是系統目標，它必須是業務導向、可度量、合理、可行的，這類需求通常來自于高層，例如專案投資人、實際用戶的管理者、市場營銷部門或產品策劃部門，

業務需求從總體上描述了為什么要開發系統（why），希望達到什么目標，比如“希望實施CRM后公司的客戶滿意度達到80％以上”，

業務需求對之后的用戶需求和功能需求起了限定作用，任何用戶和功能需求都必須符合業務需求，

2. 用戶需求

用戶需求是指描述用戶使用產品必須要完成什么任務，怎么完成需求，通常是進行用戶訪談、調查，對用戶使用的場景進行整理，從而建立從用戶角度的需求，

用戶需求必須能夠體現軟體系統將給用戶帶來的業務價值 ，也就是說用戶需求描述了用戶能使用系統來做些什么（what），這個層次的需求是非常重要的，

用戶需求可細分為：

• 基本型需求：產品功能必須滿足的用戶需求，例如社交產品的加友功能；音樂產品的聽歌功能，

• 期望型需求：用戶滿意度隨著此類需求的滿足程度而線性提升或下降，當此型別需求越得到滿足則用戶滿意度越高，反之則用戶滿意度越低，例如，音樂類產品的歌曲越多越好，

• 興奮型需求：是一種完全出乎用戶意料的屬性或功能，例如微信的搖一搖，

• 無差異型需求：這類需求無論滿足與否，用戶滿意度都不會受其影響，用戶對此因素并不在意，例如產品的簡介，

• 反向型需求：用戶沒有此需求，提供后滿意度適得其反，例如產品付費功能，

3. 功能需求

功能需求描述的是開發人員需要實作什么，是需求的主體，它描述的是開發人員如何設計具體的解決方案來實作這些需求（how），其數量往往比用戶需求高一個數量級，

這些需求記錄在軟體需求規格說明（Software Requirments Specification）中， SRS完整地描述了軟體系統的預期特性，開發、測驗、質量保證、專案管理和其他相關的專案功能都要用到 SRS，

7.3 獲取步驟

我們必須知道獲取需求的具體步驟

1. 標識專案干系人： 干系人串列
2. 與專案干系人交流：溝通計劃
3. 收集需求： 需求溝通紀要
4. 重要性排序：需求優先級
5. 選擇需求： 根據資源和約束，選擇實作的需求
6. 記錄需求：撰寫檔案

軟體研發是一個團隊性作業，各個角色協同作業，共同把專案完成，每個階段和角色的產出，又是下一階段和角色的輸入，比如作為架構師，會根據產品經理撰寫的功能需求說明書，進行整體系統架構設計，而開發人員，也會根據產品經理的需求說明書和架構師的概要設計，做詳細的設計和開發，

8. 需求要素

8.1 角色、場景

一般來說每個業務活動是對用戶使用場景的抽象（例如電商購物活動），每個業務活動可能包含多個場景（例如商品瀏覽、購物車、下單、支付），分析使用場景時應按照業務活動為主線逐個進行分析，每個業務活動分析時應包含如下內容：

1.明確活動執行角色

2.明確活動執行的前置條件

3.明確不同場景：

一個業務活動可能包含正常的使用場景、備選使用場景和例外使用場景

4.明確每個場景的執行步驟

5.業務規則和約束：

明確在每個業務活動下應遵循的業務規則和約束，這里一般是與業務流程相關的行為規則，或與資料物體相關的資料規則（比如某個欄位的長度）

8.2 業務流程

針對流程類需求必須進行業務流程分析，需求人員進行流程分析應遵循如下方法：

（1）業務流程確認

一個流程為一個業務事件，一般是外部角色發起或系統內部主動發起（比如時間事件或狀態事件），發起后會觸發一系列業務活動，

（2）角色及業務活動確認

流程圖中的每個泳道都必須對應到角色，每個角色對應多個業務活動，需求人員在確認業務活動時一定要保證活動的粒度，一個業務活動一定是由一個角色完成且每個業務活動都是有價值的，

（3）業務活動間關系及資料確認

確定所有業務活動的前后關系，并明確流程間傳遞的資料物體，

（4）流程整體瓶頸分析

一般若某個角色業務活動作業量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散作業量提出流程優化建議，

8.3 資料物體

針對流程類需求需要分析各業務活動傳遞的資料物體，統計分析類需求需要分析統計查詢條件資料物體和展現資料物體，介面類需求需要分析介面傳遞資料物體，具體分析包含如下內容：

1.明確資料物體

確認需要分析的所有資料物體，明確哪些為系統原有物體、哪些為新增物體、哪些為改造物體，

2.明確所有資料物體間關系

物體間關系包含（1對1、1對多、多對多），另外需要分析資料物體變更是否需要保留版本，物體洗掉（邏輯洗掉、物理洗掉）是否影響其它資料物體，

3.明確資料物體欄位

針對新增資料或改造資料物體需要明確新增欄位的名稱、欄位型別、是否必填、欄位取值方式（人工輸入、系統自動繼承自其它資料物體、系統自動計算需要明確計算公式），

4.資料權限分析

需要分析不同角色在資料權限方面的差異，若涉及縱向多級用戶，要說明對于集團/省/地市用戶的資料隔離，

8.4 功能性需求

系統功能分析是結合系統現狀和上述分析進一步明確實作相應用戶場景的系統功能，主要還包含內容如下：

1.功能串列

分析得出實作上述業務活動對應的功能/介面串列，并明確新增功能、改造功能；

2.功能/介面關聯影響分析

實作某個業務活動需要新增或改造的功能對其它關聯功能/介面的影響分析，比如改造請購池受理功能，可能會影響采購專案創建功能；采購專案創建功能修改一個欄位取值范圍，會影響專案統計分析和同步ES系統介面，

3.系統互動原型分析

需求人員應遵循界面規范，并與研發溝通確定系統互動原型，幫助研發或用戶更好的理解需求場景，

在互動原型中應包含如下內容：

• 原型界面的名稱、入口，原型間關聯關系和使用角色
• 頁面內容、格式及排序方法
• 操作要點：比如互動的資訊提示、界面規則和約束（比如界面以不同顏色顯示不同的校驗結果），

4.演算法分析：

在系統功能互動時涉及比較復雜的演算法，需要單獨對演算法進行分析，

8.5 非功能性需求

包含需求的可行性分析、健壯性分析、可擴展性分析、執行效率分析，可行性分析從以下幾個方面進行：

1.技術可行性 系統互動實作方式與研發確認是否可行，需求人員在與研發溝通程序中需要不斷積累哪些功能實作在技術層面很難支撐，

2.時間可行性 根據用戶的上線時間要求分析是否可滿足要求，

3.合法合規可行性 分析用戶需求是否滿足國家法規或公司法規要求，

4.資料安全性分析 用戶需求是否滿足資訊系統安全要求，

9. 案例：電商訂單系統

9.1 概述

電商所有模塊中，訂單系統是非常核心的一個子系統，決定了整個流程能不能順暢的執行，起著承上啟下的作用，其他模塊都是圍繞訂單系統進行構建的，訂單系統出問題，或者功能流程設計不完善、不準確，將會造成整個電商系統整體或區域業務流轉不順暢，甚至導致專案的失敗，

訂單系統的作用是：管理訂單型別、訂單狀態，收集關于商品、優惠、用戶、識訓資訊、支付資訊等一系列的訂單實時資料，進行庫存更新、訂單下發等一系列動作，訂單系統業務的基本模型涉及用戶、商品（庫存）、訂單、付款，訂單基本流程是下訂單-->減庫存，這兩步必須同時完成，不能下了訂單不減庫存（超賣），或者減了庫存沒有生成訂單（少賣），

下面我們從需求分析的角度，來看一看B2C電商中先款后貨模式下的訂單系統設計的程序，

9.2 角色

一個訂單系統，涉及到的角色包括：

物體角色：

• C端用戶
• B端商戶
• 電商平臺
• 配送商
• 第三方平臺

系統關系：

9.3 場景(用例)

從用戶的角度，我們看到的用戶場景如下：

用例圖：

9.4 功能

訂單系統業務架構：

（1）訂單服務

該模塊的主要功能是用戶日常使用的服務和頁面，主要有訂單串列、訂單詳情、在線下單等，還包括為公共業務模塊提供的多維度訂單資料服務，

（2）訂單邏輯

訂單系統的核心，起著至關重要的作用，在訂單系統負責管理訂單創建、訂單支付、訂單生產、訂單確認、訂單完成、取消訂單等訂單流程，還涉及到復雜的訂單狀態規則、訂單金額計算規則以及增減庫存規則等，在4節核心功能設計中會重點來說，

（3）底層服務

資訊化建設達到一定程度的企業，一般會將公司公共服務模塊化，比如：產品，會構建對應的產品系統，代碼、資料庫，介面等相對獨立，但是，這也帶來了一個問題，比如：訂單創建的場景下需要獲取的資訊分散在各個系統，

如果需要從各個公共服務系統呼叫：一是會花費大量時間，二是代碼的維護成本非常高，因此，訂單系統接入所需的公共服務模塊介面，在訂單系統即可完成對接公共系統的服務，

9.5 物體

9.6 流程

流程是指從平臺角度出發，將訂單從創建到完成的整個流轉程序進行抽象，從而形成了一套標準流程規則，每個流程觸發的條件又可分為系統觸發和人工觸發兩種場景，

下面以一個通用B2C商城的訂單系統為例，根據其實際業務場景，其訂單流程可抽象為5大步驟：訂單創建>訂單支付>訂單生產>訂單確認>訂單完成， 如下圖：

標籤：架構設計

上一篇：socket.io中的房間是否會在一段時間后自動洗掉？

下一篇：初識設計模式 - 備忘錄模式