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步实践过程，最终推导出初步的概要架构，为下一步的细化架构提供基础。

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

五、更多信息

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

微信群：（扫码入群-名额有限）