专注于快乐的事情

软件架构漫谈

架构分类

业务架构,功能架构,(系统架构/技术架构),应用架构

业务(逻辑)架构

使用一套方法论对产品(项目)所涉及到的需求的业务进行业务边界划分,简单的讲就是根据一套逻辑思路进行业务的拆分,总体原则是对业务进行业务边界的划分,比如做一个企业订购服务网站,你需要把商品类目、商品、订单、订单服务、支付、退款很清晰的划分出来,而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。

应用架构

应用是介于业务语言与技术语言之间,是对整个系统实现的总体上的架构,他需要指出系统的层次、系统开发的原则、系统各个层次的应用服务,例如,上述系统中可以分为、数据层(资源层)、数据服务层、中间构建服务层、业务逻辑层、表现层,并写明每个层次应用服务。

数据架构

对存储数据(资源)的架构方法论,其架构原则同应用架构大同小异,即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据(数据库)策略等等。

技术架构

对上述架构中提出的功能(或服务)进行技术方案的实现。包括软件系统实现、操作系统选择、运行时设计。

架构与架构视图的关系

软件架构视图

什么是软件架构视图呢?Philippe Kruchten在其著作《Rational统一过程引论》中写道:
一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述,描述中涵盖了系统的某一特定方面,而省略了于此方面无关的实体。

架构需要描叙2个方面的内容,业务架构和技术架构。

对应需求,可以分成,功能需求和非功能需求。
功能需求分为
非功能需求包含质量属性,约束。没有完美的架构,因为任何项目都有约束。
其中质量属性又包含
运行期质量属性和开发期质量属性。
运行期质量属性,常见如高性能,易用性等。
开发期质量属性,常见如易理解性,模块间松耦合,易测试性等。
非功能需求偏技术一些。
现代的架构还需要考虑未来的扩展性的问题,这是一种艺术。

4+1视图

“4+1”视图最早由Philippe Kruchten提出,他在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文,引起了业界的极大关注,并最终被RUP采纳,现在已成为架构设计的结构标准。

如下图所示。

场景视图-用户需求

也叫用例视图,描述用户的业务场景,从用户的角度识别出业务需求,它是架构设计的起点和终点。

具体可以描叙的参考内容:业务流程图,用例图,每个用例的活动图。

逻辑视图-设计满足功能需求的架构

逻辑视图关注功能,不仅包括用户可见的功能,还包括为实现用户功能而必须提供的”辅助功能模块”。

如果设计采用面向对象的方法,逻辑视图就是对象模型。逻辑视图重点在于功能,功能包括可见的业务功能,也包括不可见的系统功能(如日志、权限、事务等)。同时更重要的是确立逻辑分层、模块划分和模块之间的依赖关系。

具体可以描叙的参考内容:
模块划分与依赖关系(逻辑结构图),业务实体,领域模型(类图)。

开发视图-设计满足开发期质量属性的架构

侧重描述开发期质量属性,软件在开发环境下的静态组织。
开发视图关注程序包,应用的统一框架,引用的类库、SDK和中间件,以及工程和包的划分规则等,规范、约束开发环境的结构。

具体可以描叙的参考内容:
开发环境,技术框架,分层策略,目录结构

处理视图-设计满足运行期质量属性的架构

描述系统的并发和同步方面的设计,侧重运行期质量属性
处理视图关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。如果系统不需要考虑这些方面,本视图可以省略。

VS开发视图:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题。

物理视图-部署相关的架构决策

也叫部署视图,描述软件如何映射到硬件,反映系统在分布/部署上的设计。

软件最终要驻留、安装或部署到硬件才能运行,物理视图关注”目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性可伸缩性等要求。

问题

类/库/服务/应用

领域模型在实现时可大可小,在业务的早期,在系统比较小的情况下,它有可能是一个类。当系统做大了以后,它可能是个 DLL 库。再做更大一点的时候,它可能是一个服务,给不同的应用去调用。每一个方法都有成为服务的潜质,特别是在系统中后期。领域模型是业务逻辑代码的施工图纸,它不仅有利于对现在系统业务逻辑的了解,同时也指导未来的架构改造。
另外一个话题,架构演化。

为什么需要进行架构验证?

将风险提前,为了有效的识别风险。可以将代价降到最低。
只有系统做一次,才不需要进行验证。
风险应该贯彻到架构的每个阶段。

为什么需要架构演化

约束在进行变化,产生的结果也进行变化。
业务的发展推生架构需要进行相应的调整。

http://www.cnitpm.com/pm/21856.html

参考

http://www.cnblogs.com/JCSU/articles/2803598.html

评论系统未开启,无法评论!