本篇主将详细的阐述架构设计过程中概要架构设计要点来和大家共同交流，掌握后续如何强化概要架构设计在架构设计中作用，帮助我们快速确认架构的方向及核心大框架。
在阐述具体的概要架构工作方法之前，还请大家先参考我们限定的业务场景：
1、HRMS系统的介绍？（涵盖哪些功能？价值和作用是什么？行业什么情况？）
本篇将围绕4类企业代表来阐述不同规模企业对于HRMS的需求及应用
3、架构师在设计该系统时的职责及具备的核心能力是什么？
概要架构阶段的特点：
满足“架构=组件+交互”的基本定义(所有架构都逃离不了该模式)
对高层组件的“职责”进行笼统界定，并给出高层组件的相互关系
不应涉及接口细节
在讲具体的概要架构设计实践之前，请大家思考以下问题：
不同系统的架构，为什么不同？
架构设计中，应何时确立架构大方向的不同？（功能、质量、约束
架构设计是功能需求驱动的，对吗？
架构设计是用例驱动的，对吗？
实际上架构设计的驱动力：功能+质量+约束
概要架构阶段还是概念视图？
阶段体现先后关系，视图体现并列关系
概要架构阶段根据重大需求、特殊需求、高风险需求形成稳定的高层架构设计成果
概念架构是一个架构设计阶段，必须在细化架构设计阶段之前，针对重大需求，特色需求、高风险需求、形成文档的高层架构设计成果。
重大需求塑造概念架构，这里的重大需求涵盖功能、质量、约束等3类需求的关键内容。
如果只考虑功能需求来设计概念架构，将导致概念架构沦为“理想化的架构”，这个脆弱的架构不久就会面临“大改”的压力，甚至直接导致项目失败。
整体可分为3个阶段：
1、通过鲁棒图：初步设计的目标就是发现职责，运用“职责协作链”原理画鲁棒图
2、高层分割：运用成熟的经验及方法论，结合场景选择合适的架构模式来确定系统的层级关系
3、质疑驱动：考虑非功能性需求来不断驱动概要架构设计过程。
鲁棒图的三种对象：
边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入、处理内部内容的解释、并表达或传递相应的结果。
控制对象对行为进行封装，描述用例中事件流的控制行为。
实体对象对信息进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系。
初步设计的目标是“发现职责”，为高层切分奠定基础
初步设计“不是”必须的，但当“待设计系统”对架构师而言并无太多直接经验时，则强烈建议进行初步设计
基于关键功能（而不是对所有功能）、借助鲁棒图（而不是序列图，序列图太细节）进行初步设计
大家看完鲁棒图发现鲁棒图也有实体、控制及边界对象，怎么这么类似web系统时用到的MVC模式，那么我们这里对比下这2个模式的异同点:
通过上面的对比我们发现，鲁棒图能够更全面的体现架构设计过程中涉及的内容，单独的架构模式更侧重其中的部分架构层次，比如逻辑架构采取MVC的模式。
1）、直接分层
2）、先划分为子系统，再针对每个子系统分层
针对高层分割，我们可以采取分阶段的模式来进行落地实践：
1、直接划分层次：直接把系统划分为多个层次，梳理清晰各层次间的关联关系
2、分为2个阶段：先划分为多个子系统，然后再梳理子系统的层次，梳理清晰没格子系统的层次关系
2、物理层：分布部署在不同机器上
3、通用性分层：通用性越多，所处层次越靠下
多层Layer架构模式
诸如我们常见的三层架构模式，三层架构(3-tierarchitecture)通常意义上的三层架构就是将整个业务应用划分为：界面层（UserInterfacelayer）、业务逻辑层（BusinessLogicLayer）、数据访问层（Dataaccesslayer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
逻辑层次的架构能帮助我们解决逻辑耦合，达到灵活配置，迁移。一个良好的逻辑分层可以带来：
A、逻辑组织代码/代码逻辑的清晰度
B、易于维护（可维护性）
C、代码更好的重用（可重用性）
D、更好的团队开发体验（开发过程支持）
Tier指代码运行的位置，多个Layer可以运行在同一个Tier上的，不同的Layer也可以运行在不同的Tier上，当然，前提是应用程序本身支持这种架构。以J2EE和.NET平台为例，大多数时候，不同的Layer之间都是直接通过DLL或者JAR包引用来完成调用的（例如：业务逻辑层需要引用数据访问层），这样部署的时候，也只能将多个Layer同时部署在一台服务器上。相反，不同的Layer之间如果是通过RPC的方式来实现通信调用的，部署的时候，便可以将不同的Layer部署在不同的服务器上面，这也是很常见的解耦设计。
一个良好的物理架构可以带来：
A、性能的提升
B、可伸缩性
C、容错性
D、安全性
并且各层的调用关系是自上而下的，越往下通用性越高。
通过“目标-场景-决策表”分析非功能需求：
通过分析关键的质量及约束内容，给出具体的场景及应对策略，梳理出清晰的决策表，在概念架构阶段融合决策表中给出的方案，最终给出初步的概念架构设计。
结合前面讲的需求梳理的要点内容，我们结合HRMS系统来进行应用实践，逐步形成概要架构设计。
A、基于RelationRose来画出鲁棒图、确定系统的边界及关键内容
1)、分析系统中的参与者及应用功能边界：
基于上面我们能够发现我们的核心功能点：
组织管理：主要实现对公司组织结构及其变更的管理；对职位信息及职位间工作关系的管理，根据职位的空缺进行人员配备；按照组织结构进行人力规划、并对人事成本进行计算和管理，支持生成机构编制表、组织结构图等
人事档案：主要实现对员工从试用、转正直至解聘或退休整个过程中各类信息的管理，人员信息的变动管理，提供多种形式、多种角度的查询、统计分析手段
劳动合同：提供对员工劳动合同的签订、变更、解除、续订、劳动争议、经济补偿的管理。可根据需要设定试用期、合同到期的自动提示
招聘管理：实现从计划招聘岗位、发布招聘信息、采集应聘者简历，按岗位任职资格遴选人员，管理面试结果到通知试用的全过程管理
绩效管理：通过绩效考核可以评价人员配置和培训的效果、对员工进行奖惩激励、为人事决策提供依据。根据不同职位在知识、技能、能力、业绩等方面的要求，系统提供多种考核方法、标准，允许自由设置考核项目，对员工的特征、行为、工作结果等进行定性和定量的考评
配置管理：系统中为了增强系统的兼容性及灵活性，增加了诸多系统开关及配置，为后续满足各类场景提供支撑。其中需要有配置项的动态分类、动态增加、修改等功能
权限管理：通用权限管理系统，支撑组织、员工、角色、菜单、按钮、数据等涵盖功能及数据全面的权限管理功能
流程管理：提供工作流引擎服务，支持自定义表单及流程，全面支撑HRMS系统中的审批流。
人力资源规划分析：提供全方位的统计分析功能，满足企业人力资源管理及规划，为后续的经营决策提供数据依据。
2)、系统边界
基于上述核心功能点，我们可以梳理出系统的边界，包含如下几个方面：
i、管理员的系统边界
由于管理员的角色定位已经做了限定，所以他需要有专门的运维管理后台，这个后台提供的功能和业务操作人员的后台功能和界面是完全不同的，所以需要单独的入口，其中的功能模块也是有区别的。所以我们可以得出管理员使用系统时的接入方式和边界。
ii、HR的系统边界
iii、员工的系统边界
对于员工来说，HRMS系统中只有部分模块式可以操作使用的，诸如考勤、报销、绩效、查看及维护个人信息等，其他的信息都是由HR填写后用户可以查看，所以从操作便捷来看，员工与HR在业务系统入口上可以是统一入口，通过权限来限制访问边界即可。
iv、公司管理者的边界
3)、数据对象
i、基础数据：系统包含的元数据、服务管理、日志、模块、基础配置、数据字典、系统管理等基础数据管理
ii、业务数据：涵盖机构、员工、HRMS系统业务及流程数据、外部第三方业务联动数据等
B、划分高层子系统
我们基于上面鲁棒图分析后的核心需求，我们给出系统的宏观的架构轮廓，这里仅考虑用户角色及职责链、从而形成上述的高层分割。
C、质量需求影响架构的基本原理：进一步质疑
1)、考虑关键质量属性中的持续可用性及可伸缩性，得出概要架构的中间成果：
2)、考虑关键质量属性中的互操作性，进一步优化概要架构的中间成果：
3)、考虑高性能，除了高负载，还需要考虑静态化、缓存等提升系统性能：
上面基本形成了一个概要架构的雏形，不过这还不够，我们还有一项关键的内容没有分析，那就是系统约束，我们需要将之前明确的关键约束进行分析拆解，转化为功能或质量要求：
D、分析约束影响架构的基本原理：直接制约、转化为功能或质量需求
分析上述表格的内容，结合上几轮分析后给出的概要架构进行验证，看看这些约束会不会影响该架构内容，然后进行优化调整：
i、业务环境及约束：目前来看，上述概要架构可以支持,不会对于当前的概要架构造成影响。
ii、使用环境约束：之前拟定的PC、App端访问模式已考虑了上述的场景，关于多语言在应用层细节设计时考虑即可。
iii、开发环境约束：概要架构还不涉及细节内容，当前的约束也不会对于架构产生较大影响
iv、技术环境约束：无影响，属于细节层面
E、基于上面几部走，我们得到了初步的概要架构，基本上符合功能、质量及约束的各类要求及场景，得出以下概要架构设计图。
基于前面对于概要架构设计推演过程的实践，我们总结概要架构过程的3个核心要点内容如下：
1、首先，需要分析找到HRMS系统中的关键功能、质量及约束
2、其次，利用鲁棒图找到系统的用户、关键功能及职责链，形成初步的子系统的拆分、过程中借助高层分割形成分层结构，不断通过质疑+解决方案的模式，应对及完善质量及约束的要求。
3、最后，通过1、2步实践过程，最终推导出初步的概要架构，为下一步的细化架构提供基础。
希望大家通过上面示例的展示，为大家后续在系统架构设计实践的过程中提供一些帮助。