HRMS(人力資源管理系統)-SaaS架構設計-概要設計實踐

1、開篇

      前期咱們針對架構準備階段及需求分析這塊咱們寫了2篇內容《HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇》《HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-下篇》內容來展開說明。

       本篇主將詳細的闡述架構設計過程當中概要架構設計要點來和你們共同交流，掌握後續如何強化概要架構設計在架構設計中做用，幫助咱們快速確認架構的方向及核心大框架。

      在闡述具體的概要架構工做方法以前，還請你們先參考咱們限定的業務場景：

     一、HRMS系統的介紹？（涵蓋哪些功能？價值和做用是什麼？行業什麼狀況？）

      請閱讀《HRMS(人力資源管理系統)-從單機應用到SaaS應用-系統介紹》

      二、本章分析的內容將圍繞4類企業表明的業務場景，（區分不一樣規模企業的關注點，規模將決定系統的設計方案）

      本篇將圍繞4類企業表明來闡述不一樣規模企業對於HRMS的需求及應用

•       A、100人如下的中小企業
•       B、500人如下的大中型企業
•       C、1000人以上的集團化大企業
•       D、全球類型的公司體系（幾萬人）

      三、架構師在設計該系統時的職責及具有的核心能力是什麼？

      請閱讀《系統架構系列-開篇介紹》

 

1、關於概要架構階段

 

1.一、概要架構的定義

       概念架構就是對系統設計的最初構想，就是把系統最關鍵的設計要素及交互機制肯定下來，而後再考慮具體的技術應用，設計出實際架構。概念架構階段主抓大局，不拘小節，不過度關注設計實現的細節內容。

       概要架構階段的特色：

Ø知足「架構=組件+交互」的基本定義(全部架構都逃離不了該模式)

Ø對高層組件的「職責」進行籠統界定，並給出高層組件的相互關係

Ø不該涉及接口細節

在講具體的概要架構設計實踐以前，請你們思考如下問題：

Ø不一樣系統的架構，爲何不一樣？

Ø架構設計中，應什麼時候確立架構大方向的不一樣？（功能、質量、約束

 

1.二、行業現狀

1.2.一、誤將「概要架構」等同於「理想架構」

架構設計是功能需求驅動的，對嗎？

架構設計是用例驅動的，對嗎？

實際上架構設計的驅動力：功能+質量+約束

1.2.二、誤把「階段」當「視圖」

概要架構階段仍是概念視圖？

階段體現前後關係，視圖體現並列關係

概要架構階段根據重大需求、特殊需求、高風險需求造成穩定的高層架構設計成果

 

1.三、主要工做內容及目標

       概念架構是一個架構設計階段，必須在細化架構設計階段以前，針對重大需求，特點需求、高風險需求、造成文檔的高層架構設計成果。

       重大需求塑造概念架構，這裏的重大需求涵蓋功能、質量、約束等3類需求的關鍵內容。

       若是隻考慮功能需求來設計概念架構，將致使概念架構淪爲「理想化的架構」，這個脆弱的架構不久就會面臨「大改」的壓力，甚至直接致使項目失敗。

 

2、概要架構階段的方法及科學實踐過程是什麼？

 

總體可分爲3個階段：

一、經過魯棒圖：初步設計的目標就是發現職責，運用「職責協做鏈」原理畫魯棒圖

二、高層分割：運用成熟的經驗及方法論，結合場景選擇合適的架構模式來肯定系統的層級關係

三、質疑驅動：考慮非功能性需求來不斷驅動概要架構設計過程。

2.一、初步設計的目標就是發現職責，運用「職責協做鏈」原理畫魯棒圖

魯棒圖的三種對象：

•邊界對象對模擬外部環境和將來系統之間的交互進行建模。邊界對象負責接 收外部輸入、處理內部內容的解釋、並表達或傳遞相應的結果。

•控制對象對行爲進行封裝，描述用例中事件流的控制行爲。

•實體對象對信息進行描述，它每每來自領域概念，和領域模型中的對象有良好的對應關係。

初步設計原則

•初步設計的目標是「發現職責」，爲高層切分奠基基礎

•初步設計「不是」必須的，但當「待設計系統」對架構師而言並沒有太多直接 經驗時，則強烈建議進行初步設計

•基於關鍵功能（而不是對全部功能）、藉助魯棒圖（而不是序列圖，序列圖太細節）進行初 步設計

       關於這幾個對象的區別，請參考《HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇》中有描述魯棒圖的基本用法說明。後續本文將直接使用再也不復述具體的用法。

       你們看完魯棒圖發現魯棒圖也有實體、控制及邊界對象，怎麼這麼相似web系統時用到的MVC模式，那麼咱們這裏對比下這2個模式的異同點:

       經過上面的對比咱們發現，魯棒圖可以更全面的體現架構設計過程當中涉及的內容，單獨的架構模式更側重其中的部分架構層次，好比邏輯架構採起MVC的模式。

2.二、高層分割（概念架構造成的具體操做方法）

1）、直接分層

2）、先劃分爲子系統，再針對每一個子系統分層

針對高層分割，咱們能夠採起分階段的模式來進行落地實踐：

一、直接劃分層次：直接把系統劃分爲多個層次，梳理清晰各層次間的關聯關係

二、分爲2個階段：先劃分爲多個子系統，而後再梳理子系統的層次，梳理清晰沒格子系統的層次關係

針對分層模式的引入，這裏分享幾類劃分模式及方法：

一、邏輯層：邏輯層，上層使用下層觀念；不關注物理劃分，也不關注通用性

二、物理層：分佈部署在不一樣機器上

三、通用性分層：通用性越多，所處層次越靠下

 

2.2.一、Layer：邏輯層

Layer：邏輯層，上層使用下層觀念；不關注物理劃分，也不關注通用性。Layer是邏輯上組織代碼的形式。好比邏輯分層中表現層，服務層，業務層，領域層，他們是軟件功能來劃分的。並不指代部署在那臺具體的服務器上或者，物理位置。

        多層Layer架構模式

       諸如咱們常見的三層架構模式，三層架構(3-tier architecture) 一般意義上的三層架構就是將整個業務應用劃分爲：界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、數據訪問層（Data access layer）。區分層次的目的即爲了「高內聚低耦合」的思想。在軟件體系架構設計中，分層式結構是最多見，也是最重要的一種結構。微軟推薦的分層式結構通常分爲三層，從下至上分別爲：數據訪問層、業務邏輯層（又或稱爲領域層）、表示層。

邏輯層次的架構能幫助咱們解決邏輯耦合，達到靈活配置，遷移。 一個良好的邏輯分層能夠帶來：

A、邏輯組織代碼/代碼邏輯的清晰度

B、易於維護（可維護性）

C、代碼更好的重用（可重用性）

D、更好的團隊開發體驗（開發過程支持）

 

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.三、通用性分層

採起通用性分層模式，原則是通用性越多，所處層次越靠下

而且各層的調用關係是自上而下的，越往下通用性越高。

2.三、質疑驅動，不斷完善系統架構（質量屬性及約束決定了架構的演變）

基於系統中的重大功能來塑造概念架構的高層框架，過程當中須要經過質量及約束等非功能性需求不斷質疑初步的概念架構，逐步讓這個概念架構完善，可以知足及支撐各種質量及約束的要求。具體的操做方法咱們能夠採起以前篇幅《HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇》中介紹的 「目標-場景-決策表」 來實現。

Ø經過「目標-場景-決策表」分析非功能需求：

經過分析關鍵的質量及約束內容，給出具體的場景及應對策略，梳理出清晰的決策表，在概念架構階段融合決策表中給出的方案，最終給出初步的概念架構設計。

 

3、基於前面分析的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、基於上面幾部走，咱們獲得了初步的概要架構，基本上符合功能、質量及約束的各種要求及場景，得出如下概要架構設計圖。

4、概要架構階段要點總結

基於前面對於概要架構設計推演過程的實踐，咱們總結概要架構過程的3個核心要點內容以下：

一、首先，須要分析找到HRMS系統中的關鍵功能、質量及約束

二、其次，利用魯棒圖找到系統的用戶、關鍵功能及職責鏈，造成初步的子系統的拆分、過程當中藉助高層分割造成分層結構，不斷經過質疑+解決方案的模式，應對及完善質量及約束的要求。

三、最後，經過一、2步實踐過程，最終推導出初步的概要架構，爲下一步的細化架構提供基礎。

但願你們經過上面示例的展現，爲你們後續在系統架構設計實踐的過程當中提供一些幫助。

5、更多信息

關於更多的系統架構方面的知識，我已創建了交流羣，相關資料會第一時間在羣裏分享，歡迎你們入羣互相學習交流：

微信羣：（掃碼入羣-名額有限）