设为首页 加入收藏

TOP

HRMS(人力资源管理系统)-SaaS架构设计-概要设计实践(一)
2019-09-17 17:45:03 】 浏览:58
Tags: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、主要工作内容及目标

image

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

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

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

 

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

 

image

整体可分为3个阶段:

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

2、高层分割:运用成熟的经验及方法论,结合场景选择合适的架构模式来确定系统的层级关系

3、质疑驱动:考虑非功能性需求来不断驱动概要架构设计过程。

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

image

鲁棒图的三种对象:

?边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接 收外部输入、处理内部内容的解释、并表达或传递相应的结果。

?控制对象对行为进行封装,描述用例中事件流的控制行为。

?实体对象对信息进行描述,它往往来自领域概念,和领域模型中的对象有良好的对应关系。

初步设计原则

?初步设计的目标是“发现职责”,为高层切分奠定基础

?初步设计“不是”必须的,但当“待设计系统”对架构师而言并无太多直接 经验时,则强烈建议进行初步设计

?基于关键功能(而不是对所有功能)、借助鲁棒图(而不是序列图,序列图太细节)进行初 步设计

image

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

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

image

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

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

1)、直接分层

image

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

image

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

1、直接划分层次:直接把系统划分为多个层次,梳理清晰各层次间的关联关系

2、分为2个阶段:先划分为多个子系统,然后再梳理子系统的层次,梳理清晰没格子系统的层次关系

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

1、逻辑层:逻辑层,上层使用下层观念;不关注物理划分,也不关注通用性

2、物理层:分布部署在不同机器上

3、通用性分层:通用性越多,所处层次越靠下

 

2.2.1、Layer:逻辑层

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

首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇pyhton 面向对象之 小明左右手换牌 下一篇IOC的理解,整合AOP,解耦对Service..

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目