前言
架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。
本文来说一下如何写架构设计说明书
需求
那么到底如何编写架构设计说明书?该说明书应该包括哪些方面的内容呢?我们知道,架构设计说明书是阐述系统架构具体内容的,
架构的本质是呈现三大能力:
因此从这个角度看,对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能力的,
让我们逐个分析:
系统如何面向最终用户提供支撑能力:
这一点是要从系统自身的能力来看,即本系统到底应该具备哪些功能,各功能间如何协作以满足支撑最终用户的使用,其实就是要讲系统的功能架构或逻辑架构,
回答系统从功能粒度上划分了几个功能模块或子系统,各模块或子系统之间的内部接口关系如何等问题。
当然还有一个需要考虑的问题,在纵向维度上,随着架构设计理念的不断发展,
逻辑架构模型从最初的展示-数据两层模型,到展示-逻辑-数据(所谓的MVC)三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型,
不同层次表明系统内部设计的精细程度,因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。尤其是对于Browser/Server架构模式的MIS类系统,这种层次更为常见。
另外,用户相对于机器来说对系统提供的能力是有个人喜好要求的,不仅要求系统能提供支撑,而且还要更加稳定的、更方便的、灵活的、快速的等提供,
这就需要在架构设计说明书中增加所谓非功能性的设计,
通过参考技术评审指标,保证系统架构设计满足用户和系统对非功能质量的需求:
非功能质量需求的概述
核心非功能质量:
核心质量 | 描述 |
高性能 | 运行效率高,性价比高 |
可用性 | 持续可用性,缩短宕机时间,出错恢复,可靠性 |
可伸缩 | 垂直伸缩,水平伸缩 |
可扩展 | 可插拔,组件重用 |
安全性 | 数据安全,加密,熔断,防攻击 |
其他非功能质量:
核心质量 | 描述 |
可监控性 | 快速发现,快速定位,快速解决 |
可测试性 | 可灰度,可预览,可Mock,可拆解 |
鲁棒性 | 容错性,可恢复性 |
可维护性 | 易于维护,监控,运营,扩展 |
可重用性 | 可移植性,解耦 |
易用性 | 可操作性 |
非功能质量需求的具体指标
主要分为4部分:应用服务器、数据库、缓存和消息队列
根据应用层的访问量和访问峰值,计算需要消息队列传递的数据内容和数据量,
计算出的消息队列资源的数量和配置,部署结构等。
部署结构 | 容量与性能 | 其他 |
复制模型 | 每天平均数据增量 | 消费线程池模型 |
失效转移 | 消息持久的过期时间 | 分片策略 |
持久策略 | 每秒读峰值 | 消息的可靠投递 |
每秒写峰值 | ||
每条消息的大小 | ||
平均延迟 | ||
最大延迟 |
系统如何面向外部系统提供交互能力:
这一点是要把系统当成一个完整的整体,阐述它如何与外部的系统发生调用关系,外部系统为它提供了哪些开放接口,它又为外部系统提供了哪些外部接口和能力,
同时,在这种相互的调用关系中它处于整个IT架构的何种位置,这其实就是在说系统的整体架构。另外,如果我们把操作系统和硬件服务器也当成一类特殊的外部系统的话,
就需要说明系统如何基于操作系统利用硬件服务器来提供计算、存储、网络等能力,系统如何把自己拆分成不同的部分以便部署在服务器上,这其实说的是部署架构。
如何面向企业数据提供处理能力:
信息系统的原始驱动力就是人们需要借助计算机的强大计算能力来辅助处理大量数据,从而形成可理解的信息,并最终形成可掌握的知识。
因此数据处理是系统的根本目的,至关重要,在架构设计说明书中需要单独描述系统对数据的处理能力,即我们所谓的系统数据架构。
这还是可以从对外和对内两个角度来看,对外即需要说明本系统处理的数据在整个企业数据流中所处的位置,与相关的上下游数据之间的关系,
本系统需要从数据上游的外部系统获取哪些数据?又需要为数据下游的系统提供哪些数据;对内需要说明本系统根据业务需求设计了哪些关键数据表,
它们之间是何种主外键关系,是否需要从外部导入数据为系统做数据初始化等。当然还有对数据管理的描述,包括如何做数据冗余设计,备份机制,数据安全管理机制等。
好,分析完这三种能力,我们几乎就找出了架构设计说明书中应该包括的内容,包括:
综上,我们就可以得到一份完整的架构设计说明书的结构及应该包含的内容,其大致章节应该是这样的:
以上,便是我认为一份较为完整的架构设计说明书应该包括的内容了。
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删