HRMS(人力資源管理系統)-SaaS架構設計-概要設計實踐
一、開篇
前期我們針對架構準備階段及需求分析這塊我們寫了2篇內容《 ofollow,noindex" target="_blank"> HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇 》《 HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-下篇 》內容來展開說明。
本篇主將詳細的闡述架構設計過程中概要架構設計要點來和大家共同交流，掌握後續如何強化概要架構設計在架構設計中作用，幫助我們快速確認架構的方向及核心大框架。
在闡述具體的概要架構工作方法之前，還請大家先參考我們限定的業務場景：
1、HRMS系統的介紹？（涵蓋哪些功能？價值和作用是什麼？行業什麼情況？）
請閱讀 《 HRMS(人力資源管理系統)-從單機應用到SaaS應用-系統介紹 》
2、本章分析的內容將圍繞4類企業代表的業務場景，（區分不同規模企業的關注點，規模將決定系統的設計方案）
本篇將圍繞4類企業代表來闡述不同規模企業對於HRMS的需求及應用
- A、100人以下的中小企業
- B、500人以下的大中型企業
- C、1000人以上的集團化大企業
- D、全球型別的公司體系（幾萬人）
3、架構師在設計該系統時的職責及具備的核心能力是什麼？
請閱讀 《 系統架構系列-開篇介紹 》
一、關於概要架構階段
1.1、概要架構的定義
概念架構就是對系統設計的最初構想，就是把系統最關鍵的設計要素及互動機制確定下來，然後再考慮具體的技術應用，設計出實際架構。概念架構階段主抓大局，不拘小節，不過分關注設計實現的細節內容。
概要架構階段的特點：
Ø滿足“架構=元件+互動”的基本定義(所有架構都逃離不了該模式) Ø對高層元件的“職責”進行籠統界定，並給出高層元件的相互關係 Ø不應涉及介面細節
在講具體的概要架構設計實踐之前，請大家思考以下問題：
Ø 不同系統的架構，為什麼不同？
Ø 架構設計中，應何時確立架構大方向的不同？ （功能、質量、約束
1.2、行業現狀
1.2.1、誤將“概要架構”等同於“理想架構”
架構設計是功能需求驅動的，對嗎？
架構設計是用例驅動的，對嗎？
實際上架構設計的驅動力：功能+質量+約束
1.2.2、誤把“階段”當“檢視”
概要架構階段還是概念檢視？
階段體現先後關係，檢視體現並列關係
概要架構階段根據重大需求、特殊需求、高風險需求形成穩定的高層架構設計成果
1.3、主要工作內容及目標
概念架構是一個架構設計階段，必須在細化架構設計階段之前，針對重大需求，特色需求、高風險需求、形成文件的高層架構設計成果。
重大需求塑造概念架構，這裡的重大需求涵蓋功能、質量、約束等3類需求的關鍵內容。
如果只考慮功能需求來設計概念架構，將導致概念架構淪為“理想化的架構”，這個脆弱的架構不久就會面臨“大改”的壓力，甚至直接導致專案失敗。
二、概要架構階段的方法及科學實踐過程是什麼？
整體可分為3個階段：
1、通過魯棒圖：初步設計的目標就是發現職責，運用“職責協作鏈”原理畫魯棒圖 2、高層分割：運用成熟的經驗及方法論，結合場景選擇合適的架構模式來確定系統的層級關係 3、質疑驅動：考慮非功能性需求來不斷驅動概要架構設計過程。
2.1、 初步設計的目標就是發現職責，運用“職責協作鏈”原理畫魯棒圖
魯棒圖的三種物件：
•邊界物件對模擬外部環境和未來系統之間的互動進行建模。邊界物件負責接 收外部輸入、處理內部內容的解釋、並表達或傳遞相應的結果。 •控制物件對行為進行封裝，描述用例中事件流的控制行為。 •實體物件對資訊進行描述，它往往來自領域概念，和領域模型中的物件有良好的對應關係。
初步設計原則
•初步設計的目標是“發現職責”，為高層切分奠定基礎 •初步設計“不是”必須的，但當“待設計系統”對架構師而言並無太多直接 經驗時，則強烈建議進行初步設計 •基於關鍵功能（而不是對所有功能）、藉助魯棒圖（而不是序列圖，序列圖太細節）進行初 步設計
關於這幾個物件的區別，請參考《 HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇 》中有描述魯棒圖的基本用法說明。後續本文將直接使用不再複述具體的用法。
大家看完魯棒圖發現魯棒圖也有實體、控制及邊界物件，怎麼這麼類似web系統時用到的MVC模式，那麼我們這裡對比下這2個模式的異同點:
通過上面的對比我們發現，魯棒圖能夠更全面的體現架構設計過程中涉及的內容，單獨的架構模式更側重其中的部分架構層次，比如邏輯架構採取MVC的模式。
2.2、高層分割（概念架構形成的具體操作方法）
1）、直接分層
2）、先劃分為子系統，再針對每個子系統分層
針對高層分割，我們可以採取分階段的模式來進行落地實踐：
1、直接劃分層次：直接把系統劃分為多個層次，梳理清晰各層次間的關聯關係 2、分為2個階段：先劃分為多個子系統，然後再梳理子系統的層次，梳理清晰沒格子系統的層次關係
針對分層模式的引入，這裡分享幾類劃分模式及方法：
1、邏輯層： 邏輯層，上層使用下層觀念； 不關注物理劃分，也不關注通用性
2、物理層：分佈部署在不同機器上
3、通用性分層：通用性越多，所處層次越靠下
2.2.1、Layer：邏輯層
Layer：邏輯層，上層使用下層觀念； 不關注物理劃分，也不關注通用性。Layer是邏輯上組織程式碼的形式。比如邏輯分層中表現層，服務層，業務層，領域層，他們是軟體功能來劃分的。並不指代部署在那臺具體的伺服器上或者，物理位置。
多層Layer架構模式
諸如我們常見的三層架構模式，三層架構 (3-tier architecture) 通常意義上的三層架構就是將整個業務應用劃分為：介面層（User Interface layer）、業務邏輯層（Business Logic Layer）、資料訪問層（Data access layer）。區分層次的目的即為了“ 高內聚低耦合 ”的思想。在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、業務邏輯層（又或稱為領域層）、表示層。
邏輯層次的架構能幫助我們解決邏輯耦合，達到靈活配置，遷移。 一個良好的邏輯分層可以帶來：
A、邏輯組織程式碼/程式碼邏輯的清晰度 B、易於維護（可維護性） C、程式碼更好的重用（可重用性） D、更好的團隊開發體驗（開發過程支援）
2.2.2、Tier：物理層
Tier：物理層，各分層分佈部署在不同機器上，Tier這指程式碼執行部署的具體位置，是一個物理層次上的劃為，Tier就是指邏輯層Layer具體的執行位置。所以邏輯層可以部署或者遷移在不同物理層，一個物理層可以部署執行多個邏輯層。
Tier指程式碼執行的位置，多個Layer可以執行在同一個Tier上的，不同的Layer也可以執行在不同的Tier上，當然，前提是應用程式本身支援這種架構。以J2EE和.NET平臺為例，大多數時候，不同的Layer之間都是直接通過DLL或者JAR包引用來完成呼叫的（例如：業務邏輯層需要引用資料訪問層），這樣部署的時候，也只能將多個Layer同時部署在一臺伺服器上。相反，不同的Layer之間如果是通過RPC的方式來實現通訊呼叫的，部署的時候，便可以將不同的Layer部署在不同的伺服器上面，這也是很常見的解耦設計。
一個良好的物理架構可以帶來：
A、效能的提升 B、可伸縮性 C、容錯性 D、安全性
2.2.3、通用性分層
採取通用性分層模式，原則是通用性越多，所處層次越靠下
並且各層的呼叫關係是自上而下的，越往下通用性越高。
2.3、質疑驅動，不斷完善系統架構（質量屬性及約束決定了架構的演變）
基於系統中的重大功能來塑造概念架構的高層框架，過程中需要通過質量及約束等非功能性需求不斷質疑初步的概念架構，逐步讓這個概念架構完善，能夠滿足及支撐各類質量及約束的要求。具體的操作方法我們可以採取之前篇幅《 HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇 》中介紹的 “目標-場景-決策表” 來實現。
Ø通過“目標-場景-決策表”分析非功能需求：
通過分析關鍵的質量及約束內容，給出具體的場景及應對策略，梳理出清晰的決策表，在概念架構階段融合決策表中給出的方案，最終給出初步的概念架構設計。
三、基於前面分析的HRMS系統？我們如何下手開始？
結合前面講的需求梳理的要點內容，我們結合HRMS系統來進行應用實踐，逐步形成概要架構設計。
A、基於RelationRose 來畫出魯棒圖、確定系統的邊界及關鍵內容
1)、分析系統中的參與者及應用功能邊界：
基於上面我們能夠發現我們的核心功能點：
組織管理：主要實現對公司組織結構及其變更的管理；對職位資訊及職位間工作關係的管理，根據職位的空缺進行人員配備；按照組織結構進行人力規劃、並對人事成本進行計算和管理，支援生成機構編制表、組織結構圖等
人事檔案：主要實現對員工從試用、轉正直至解聘或退休整個過程中各類資訊的管理，人員資訊的變動管理，提供多種形式、多種角度的查詢、統計分析手段
勞動合同：提供對員工勞動合同的簽訂、變更、解除、續訂、勞動爭議、經濟補償的管理。可根據需要設定試用期、合同到期的自動提示
招聘管理：實現從計劃招聘崗位、釋出招聘資訊、採集應聘者簡歷，按崗位任職資格遴選人員，管理面試結果到通知試用的全過程管理
薪酬福利：工資管理系統適用於各類企業、行政、事業及科研單位，直接整合考勤、績效考核等資料，主要提供工資核算、工資發放、經費計提、統計分析等功能。支援工資的多次或分次發放；支援代扣稅或代繳稅；工資發放支援銀行代發，提供代發資料的輸出功能，同時也支援現金髮放，提供分錢清單功能。經費計提的內容和計提的比率可以進行設定；福利管理系統提供員工的各項福利基金的提取和管理功能。主要包括定義基金型別、設定基金提取的條件，進行基金的日常管理，並提供相應的統計分析，基金的日常管理包括基金定期提取、基金的補繳、轉入轉出等。此外，提供向相關管理機關報送相關報表的功能
行政管理：主要提供對員工出勤情況的管理，幫助企業完善作業制度。主要包括各種假期的設定、班別的設定、相關考勤專案的設定，以及調班、加班、公出、請假的管理、遲到早退的統計、出勤情況的統計等。提供與各類考勤機系統的介面，併為薪資管理系統提供相關資料。支援通知公告分發，支援會議室/車輛等資源預定並同步日曆，支援調研和投票問卷，支援活動管理的報名/簽到/統計等，支援人員的獎懲管理並與人事檔案關聯，支援活動的抽獎管理等
培訓管理：根據崗位設定及績效考核結果，確定必要的培訓需求；為員工職業生涯發展制定培訓計劃；對培訓的目標、課程內容、授課教師、時間、地點、裝置、預算等進行管理，對培訓人員、培訓結果、培訓費用進行管理
績效管理：通過績效考核可以評價人員配置和培訓的效果、對員工進行獎懲激勵、為人事決策提供依據。根據不同職位在知識、技能、能力、業績等方面的要求，系統提供多種考核方法、標準，允許自由設定考核專案，對員工的特徵、行為、工作結果等進行定性和定量的考評
配置管理：系統中為了增強系統的相容性及靈活性，增加了諸多系統開關及配置，為後續滿足各類場景提供支撐。其中需要有配置項的動態分類、動態增加、修改等功能
許可權管理：通用許可權管理系統，支撐組織、員工、角色、選單、按鈕、資料等涵蓋功能及資料全面的許可權管理功能
流程管理：提供工作流引擎服務，支援自定義表單及流程，全面支撐HRMS系統中的審批流。
人力資源規劃分析：提供全方位的統計分析功能，滿足企業人力資源管理及規劃，為後續的經營決策提供資料依據。
2)、系統邊界
基於上述核心功能點，我們可以梳理出系統的邊界，包含如下幾個方面：
i、管理員的系統邊界
由於管理員的角色定位已經做了限定，所以他需要有專門的運維管理後臺，這個後臺提供的功能和業務操作人員的後臺功能和介面是完全不同的，所以需要單獨的入口，其中的功能模組也是有區別的。所以我們可以得出管理員使用系統時的接入方式和邊界。
ii、HR的系統邊界
HR的角色承擔業務管理的相關職責，諸如HR模組中的審批環節，他們既有業務發起的操作又有審批環節的操作，所以相對來說HR角色的使用邊界會更廣泛，相比員工來說。我們發現HR在使用時需要有單獨的系統入口，並且分配給他們對應的業務模組及功能。
iii、員工的系統邊界
對於員工來說，HRMS系統中只有部分模組式可以操作使用的，諸如考勤、報銷、績效、檢視及維護個人資訊等，其他的資訊都是由HR填寫後用戶可以檢視，所以從操作便捷來看，員工與HR在業務系統入口上可以是統一入口，通過許可權來限制訪問邊界即可。
iv、公司管理者的邊界
公司的管理者相比員工具有相應的業務及資料管理許可權，同時會在審批流環節中承擔稽核者的身份，諸多業務流程都和管理者相關，所以相比員工來說，公司管理者的業務及操作許可權較大，更多的上下級管理方面的業務內容較多，同時還可以完成員工角色操作的相關業務。
3)、資料物件
i、基礎資料：系統包含的元資料、服務管理、日誌、模組、基礎配置、資料字典、系統管理等基礎資料管理
ii、業務資料：涵蓋機構、員工、HRMS系統業務及流程資料、外部第三方業務聯動資料等
iii、其他資料：涵蓋 諸如檔案、圖片、視訊等其他型別的資料；統計分析後的結果資料；與第三方系統互動或留存的資料等相關內容。其他諸如log日誌等資料資訊。
B、劃分高層子系統
我們基於上面魯棒圖分析後的核心需求，我們給出系統的巨集觀的架構輪廓，這裡僅考慮使用者角色及職責鏈、從而形成上述的高層分割。
C、 質量需求影響架構的基本原理：進一步質疑
結合前面我們已經梳理過的關鍵的質量及約束，具體請參考《 HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-下篇 》，由於篇幅關係我就不詳細列舉，下面基於這些質量屬性及約束我們來進一步完善概要架構：
1)、考慮關鍵質量屬性中的持續可用性及可伸縮性，得出概要架構的中間成果：
2)、考慮關鍵質量屬性中的互操作性，進一步優化概要架構的中間成果：
3)、考慮高效能，除了高負載，還需要考慮靜態化、快取等提升系統性能：
上面基本形成了一個概要架構的雛形，不過這還不夠，我們還有一項關鍵的內容沒有分析，那就是系統約束，我們需要將之前明確的關鍵約束進行分析拆解，轉化為功能或質量要求：
D、分析約束影響架構的基本原理：直接制約、轉化為功能或質量需求
分析上述表格的內容，結合上幾輪分析後給出的概要架構進行驗證，看看這些約束會不會影響該架構內容，然後進行優化調整：
i、業務環境及約束 ： 目前來看，上述概要架構可以支援,不會對於當前的概要架構造成影響。
ii、使用環境約束： 之前擬定的PC、App端訪問模式已考慮了上述的場景，關於多語言在應用層細節設計時考慮即可。
iii、開發環境約束： 概要架構還不涉及細節內容，當前的約束也不會對於架構產生較大影響
iv、技術環境約束： 無影響，屬於細節層面
E、基於上面幾部走，我們得到了初步的概要架構，基本上符合功能、質量及約束的各類要求及場景，得出以下概要架構設計圖。
四、概要架構階段要點總結
基於前面對於概要架構設計推演過程的實踐，我們總結概要架構過程的3個核心要點內容如下：
1、首先，需要分析找到HRMS系統中的關鍵功能、質量及約束
2、其次，利用魯棒圖找到系統的使用者、關鍵功能及職責鏈，形成初步的子系統的拆分、過程中藉助高層分割形成分層結構，不斷通過質疑+解決方案的模式，應對及完善質量及約束的要求。
3、最後，通過1、2步實踐過程，最終推匯出初步的概要架構，為下一步的細化架構提供基礎。
希望大家通過上面示例的展示，為大家後續在系統架構設計實踐的過程中提供一些幫助。
五、更多資訊
關於更多的系統架構方面的知識，我已建立了交流群，相關資料會第一時間在群裡分享，歡迎大家入群互相學習交流：
微信群：（掃碼入群-名額有限）
