HRMS(人力资源管理系统)-SaaS架构设计-概要设计实践

Posted 2021-01-11 hegezhou_hot

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HRMS(人力资源管理系统)-SaaS架构设计-概要设计实践相关的知识，希望对你有一定的参考价值。

一、开篇

前期我们针对架构准备阶段及需求分析这块我们写了2篇内容《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、技术环境约束：无影响，属于细节层面