在規劃一個信息系統時，常常有很多人一開始就畫原型并且做一些主菜單子菜單的劃分，這樣的方法是存在很大問題的，對系統邏輯的理解只停留在表面。

沒錯，在設計系統時最開始確實是要定義好模塊結構的劃分，但是劃分的方法不應該按照功能模塊而是按照業務邏輯進行劃分。信息系統只有兩個作用，一個是解決問題，另一個是業務提升。首先在規劃系統時要思考這個系統的作用到底是解決了什么問題或者對企業帶來了怎么樣的提升。在這個大的環境下確定了之后，需求分析的階段，應該按照業務的職責區塊來劃分子系統。

這張圖應該是很普遍而且典型的后臺管理系統，但是這樣的系統無論是在開發還是使用我認為都是達不到出色的。圖中的板塊劃分采用"業務名詞+管理"來進行命名，實際上也就是以"物"為線索貫穿整個系統。但是在實際操作中物與物之間的傳遞都是交錯在一起的，例如圖中的項目管理板塊中包含了"合同管理"，在合同管理板塊中又包含了"合同管理"那么究竟是哪個進行管理呢，項目管理中是否又包含權限的區分呢，這樣的劃分明顯是有問題的。我在另一個回答上提到過"窮盡不重復"的劃分方法，其實在這里就可以體現出作用來。

那么正確的后臺劃分子系統的方式應該是按照業務流程來劃分，以"事"為線索貫穿系統。采用業務流程的環節進行劃分可以有效的避免重復和混亂的現象，對整個系統的架構都是非常清晰明了的。想要以"事"為線索進行梳理，有一個很好的方法就是使用UML中的構件圖的來解決。對于產品人員，只需要理解構件圖的思想，畫出一個輕量級的框架。

首先在構件圖中兩個最重要的概念構件和接口對應著事件和流程，接口與接口之間只存在實現(代表這個流程由這個事件提供的)和使用(代表這個事件要使用這個流程)這兩個關系。理解了這一概念之后就可以對事與事，事與流程，流程與流程之間進行連接。

畫構件圖，第一步是識別建模的構建集合，也就是對主題域進行劃分。可以按照工作職責范圍(部門)劃分成不同的主題域，劃分的時候也可以根據需要進行多級的嵌套，這樣可以更容易理解上下級之間的關聯。例如軟件開發商可以按照開發人員，產品人員，銷售人員職責不同進行第一級區塊劃分，然后再根據開發人員負責的不同環節進行第二級部門的劃分。那么根據區塊就可以很容易劃分出"銷售"和"研發"兩個主題域。

在研發這個主題域內主要負責針對軟件研發進行管理，經過設計，研發，測試這幾個階段生產出成型的軟件。那么這塊就可以命名為"研發管理系統子系統"。

在銷售這個主題域內主要負責對客戶的銷售，客戶培訓，售后服務等，因此這塊可以命名為"客戶服務管理子系統"。

在一般的系統中往往會加入后勤板塊，在這個板塊內含有硬件，財政和人員這些基本模板，可以劃分成“硬件服務管理子系統”，"財政管理子系統"和"人員管理子系統"。后面兩個子系統按照范圍界定的原則相對獨立，所以在前期設計中暫不考慮。

第二步需要把功能不同的模塊劃分成構件，同時確定構件與構件之間的接口，也就是開始繪制構件圖。首先每一個主題域就是一個構件，這個比較好理解。先分析各個主題域之間的關系，四個系統兩兩之間有不同的關系。因為人員管理子系統相對比較獨立，所以這塊可以最后考慮。

"研發管理系統子系統"與"客戶服務管理子系統":研發管理需要獲取客戶服務管理中的訂單詳情、研發要求、客戶資料等；而客戶服務管理需要獲取研發管理中的項目進展、功能設置等。

"研發管理系統子系統"與"硬件服務管理子系統":研發管理需要知道數據庫和服務器的情況，后臺資源占用的情況；硬件服務管理需要獲取研發團隊的項目進度，功能規劃和版本維護的情況。

"客戶服務管理子系統"與"硬件服務管理子系統": 硬件服務管理需要知道客戶的基本信息以便確定投入什么硬件支持；客戶服務管理系統一般就不需要從后臺服務系統獲取信息。

（上圖是一個比較簡單的原型，實際規劃還要考慮主題域之間更多關聯）

最后一步進行主題域范圍的明確，界定每個主題域內進行的功能以及相關的事件。在一些書籍中也把這個關系成為上下文關系，即主題域與功能之間父級與子級的概念。在這個階段要考慮到Customer與Worker之間的關系。找到系統中所有的客戶，考慮這些客戶會引起什么事件的發生，這些事件會引起Worker什么樣的工作，講這些都考慮進來。然后再補充Worker主動發起的動作，那么一個系統的所有事件就能沒有遺漏地梳理完整了。這里值得注意的是，對于研發管理子系統而言，其他的客服管理，財政管理都屬于是客戶關系。他們對于研發關系系統屬于消費者的動作。

通過以上三步可以把一個系統大致的框架搭建起來。這樣搭建的好處在于系統的業務流程很清晰，無論是對于研發還是使用者而言都是有好處的，每個人都能清楚地意識到自己在做什么事情。上述分析方法是徐峰老師提出的SERU需求分析法中關于主題域確定，也就是系統框架結構確定的第一步，這也是設計一個系統最根基的地方，然后才是去考慮更細化，更精準的業務流程設計。把根基打好再去做子系統內部的規劃就變得比較簡單。對于一個系統，在設計時一定要有“自上而下”的思想，從最大的環境去考慮問題，這樣才不會在后期規劃中因為突然插入的東西變得混亂。

---

justinlam。一個產品，半個設計。專注企業信息系統的研究與總結，擅長OA、CRM與ERP系統的架構與規劃。愛好業務需求分析與互聯網產品設計。（知乎專欄：遇見產品）

本文由PMCAFF專欄作者?@justinlam?原創發布于PMCAFF產品社區（www.pmcaff.com），未經許可，禁止轉載。

總結

以上是生活随笔為你收集整理的如何规划系统的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。