一、开篇

      前期我们针对架构准备阶段及需求分析这块我们写了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、主要工作内容及目标

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

       概念架构是一个架构设计阶段,必须在细化架构设计阶段之前,针对重大需求,特色需求、高风险需求、形成文档的高层架构设计成果。

       重大需求塑造概念架构,这里的重大需求涵盖功能、质量、约束等3类需求的关键内容。

       如果只考虑功能需求来设计概念架构,将导致概念架构沦为“理想化的架构”,这个脆弱的架构不久就会面临“大改”的压力,甚至直接导致项目失败。


二、概要架构阶段的方法及科学实践过程是什么?


HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

整体可分为3个阶段:

2.1、初步设计的目标就是发现职责,运用“职责协作链”原理画鲁棒图

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

鲁棒图的三种对象:

初步设计原则

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

       关于这几个对象的区别,请参考《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》中有描述鲁棒图的基本用法说明。后续本文将直接使用不再复述具体的用法。

       大家看完鲁棒图发现鲁棒图也有实体、控制及边界对象,怎么这么类似web系统时用到的MVC模式,那么我们这里对比下这2个模式的异同点:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

       通过上面的对比我们发现,鲁棒图能够更全面的体现架构设计过程中涉及的内容,单独的架构模式更侧重其中的部分架构层次,比如逻辑架构采取MVC的模式。

2.2、高层分割(概念架构形成的具体操作方法)

1)、直接分层

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

2)、先划分为子系统,再针对每个子系统分层

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

针对高层分割,我们可以采取分阶段的模式来进行落地实践:

针对分层模式的引入,这里分享几类划分模式及方法:


2.2.1、Layer:逻辑层

Layer:逻辑层,上层使用下层观念;不关注物理划分,也不关注通用性。Layer是逻辑上组织代码的形式。比如逻辑分层中表现层,服务层,业务层,领域层,他们是软件功能来划分的。并不指代部署在那台具体的服务器上或者,物理位置。

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

        多层Layer架构模式

       诸如我们常见的三层架构模式,三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或称为领域层)、表示层。

逻辑层次的架构能帮助我们解决逻辑耦合,达到灵活配置,迁移。 一个良好的逻辑分层可以带来:

2.2.2、Tier:物理层

Tier:物理层,各分层分布部署在不同机器上,Tier这指代码运行部署的具体位置,是一个物理层次上的划为,Tier就是指逻辑层Layer具体的运行位置。所以逻辑层可以部署或者迁移在不同物理层,一个物理层可以部署运行多个逻辑层。

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

       Tier指代码运行的位置,多个Layer可以运行在同一个Tier上的,不同的Layer也可以运行在不同的Tier上,当然,前提是应用程序本身支持这种架构。以J2EE和.NET平台为例,大多数时候,不同的Layer之间都是直接通过DLL或者JAR包引用来完成调用的(例如:业务逻辑层需要引用数据访问层),这样部署的时候,也只能将多个Layer同时部署在一台服务器上。相反,不同的Layer之间如果是通过RPC的方式来实现通信调用的,部署的时候,便可以将不同的Layer部署在不同的服务器上面,这也是很常见的解耦设计。

一个良好的物理架构可以带来:

2.2.3、通用性分层

采取通用性分层模式,原则是通用性越多,所处层次越靠下

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

并且各层的调用关系是自上而下的,越往下通用性越高。

2.3、质疑驱动,不断完善系统架构(质量属性及约束决定了架构的演变)

基于系统中的重大功能来塑造概念架构的高层框架,过程中需要通过质量及约束等非功能性需求不断质疑初步的概念架构,逐步让这个概念架构完善,能够满足及支撑各类质量及约束的要求。具体的操作方法我们可以采取之前篇幅《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》中介绍的 “目标-场景-决策表” 来实现。

Ø通过“目标-场景-决策表”分析非功能需求:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

通过分析关键的质量及约束内容,给出具体的场景及应对策略,梳理出清晰的决策表,在概念架构阶段融合决策表中给出的方案,最终给出初步的概念架构设计。


三、基于前面分析的HRMS系统?我们如何下手开始?

结合前面讲的需求梳理的要点内容,我们结合HRMS系统来进行应用实践,逐步形成概要架构设计。

A、基于RelationRose 来画出鲁棒图、确定系统的边界及关键内容

1)、分析系统中的参与者及应用功能边界:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

基于上面我们能够发现我们的核心功能点:

2)、系统边界

基于上述核心功能点,我们可以梳理出系统的边界,包含如下几个方面:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

i、管理员的系统边界

       由于管理员的角色定位已经做了限定,所以他需要有专门的运维管理后台,这个后台提供的功能和业务操作人员的后台功能和界面是完全不同的,所以需要单独的入口,其中的功能模块也是有区别的。所以我们可以得出管理员使用系统时的接入方式和边界。

ii、HR的系统边界

       HR的角色承担业务管理的相关职责,诸如HR模块中的审批环节,他们既有业务发起的操作又有审批环节的操作,所以相对来说HR角色的使用边界会更广泛,相比员工来说。我们发现HR在使用时需要有单独的系统入口,并且分配给他们对应的业务模块及功能。

iii、员工的系统边界

       对于员工来说,HRMS系统中只有部分模块式可以操作使用的,诸如考勤、报销、绩效、查看及维护个人信息等,其他的信息都是由HR填写后用户可以查看,所以从操作便捷来看,员工与HR在业务系统入口上可以是统一入口,通过权限来限制访问边界即可。

iv、公司管理者的边界

       公司的管理者相比员工具有相应的业务及数据管理权限,同时会在审批流环节中承担审核者的身份,诸多业务流程都和管理者相关,所以相比员工来说,公司管理者的业务及操作权限较大,更多的上下级管理方面的业务内容较多,同时还可以完成员工角色操作的相关业务。

3)、数据对象

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

i、基础数据:系统包含的元数据、服务管理、日志、模块、基础配置、数据字典、系统管理等基础数据管理

ii、业务数据:涵盖机构、员工、HRMS系统业务及流程数据、外部第三方业务联动数据等

iii、其他数据:涵盖诸如文件、图片、视频等其他类型的数据;统计分析后的结果数据;与第三方系统交互或留存的数据等相关内容。其他诸如log日志等数据信息。

B、划分高层子系统

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

       我们基于上面鲁棒图分析后的核心需求,我们给出系统的宏观的架构轮廓,这里仅考虑用户角色及职责链、从而形成上述的高层分割。

C、质量需求影响架构的基本原理:进一步质疑

       结合前面我们已经梳理过的关键的质量及约束,具体请参考《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-下篇》,由于篇幅关系我就不详细列举,下面基于这些质量属性及约束我们来进一步完善概要架构:

1)、考虑关键质量属性中的持续可用性及可伸缩性,得出概要架构的中间成果:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

2)、考虑关键质量属性中的互操作性,进一步优化概要架构的中间成果:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

3)、考虑高性能,除了高负载,还需要考虑静态化、缓存等提升系统性能:

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

       上面基本形成了一个概要架构的雏形,不过这还不够,我们还有一项关键的内容没有分析,那就是系统约束,我们需要将之前明确的关键约束进行分析拆解,转化为功能或质量要求:

D、分析约束影响架构的基本原理:直接制约、转化为功能或质量需求

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

分析上述表格的内容,结合上几轮分析后给出的概要架构进行验证,看看这些约束会不会影响该架构内容,然后进行优化调整:

E、基于上面几部走,我们得到了初步的概要架构,基本上符合功能、质量及约束的各类要求及场景,得出以下概要架构设计图。

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

四、概要架构阶段要点总结

基于前面对于概要架构设计推演过程的实践,我们总结概要架构过程的3个核心要点内容如下:

1、首先,需要分析找到HRMS系统中的关键功能、质量及约束

2、其次,利用鲁棒图找到系统的用户、关键功能及职责链,形成初步的子系统的拆分、过程中借助高层分割形成分层结构,不断通过质疑+解决方案的模式,应对及完善质量及约束的要求。

3、最后,通过1、2步实践过程,最终推导出初步的概要架构,为下一步的细化架构提供基础。

希望大家通过上面示例的展示,为大家后续在系统架构设计实践的过程中提供一些帮助。

五、更多信息

关于更多的系统架构方面的知识,我已建立了交流群,相关资料会第一时间在群里分享,欢迎大家入群互相学习交流:

微信群:(扫码入群-名额有限)

HRMS(人力资源管理系统)-SaaS架构设计-概要设计过程-LMLPHP

10-08 12:52