架构设计之如何写架构设计说明书

架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。在架构师整个的成长过 程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。作为一个架构师,我想尝试一下根据这三个过程对不 同能力需要,写一次系列文章,包括《架构设计三部曲之如何写架构设计说明书》、《架构设计三部曲之如何评审架构设计说明书》以及《架构设计三部曲之如何做 架构设计》,一来可以帮助自己整理思路,重新审视架构设计,二来也可以与大家分享心得,听取大家的意见,共同进步。本篇属于系列中的第一篇。

那么到底如何编写架构设计说明书?该说明书应该包括哪些方面的内容呢?我们知道,架构设计说明书是阐述系统架构具体内容的,根据我之前的文章《我的 架构观-架构未来的发展》我们明白架构的本质是呈现三大能力:即系统如何面向最终用户提供支撑能力、如何面向外部系统提供交互能力、如何面向企业数据提供 处理能力。因此从这个角度看,对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能力的,让我们逐个分析:

系统如何面向最终用户提供支撑能力:这一点是要从系统自身的能力来看,即本系统到底应该具备哪些功能,各功能间如何协作以满足支撑最终用户的使用, 其实就是要讲系统的功能架构或逻辑架构,回答系统从功能粒度上划分了几个功能模块或子系统,各模块或子系统之间的内部接口关系如何等问题。当然还有一个需 要考虑的问题,在纵向维度上,随着架构设计理念的不断发展, 逻辑架构模型从最初的展示-数据两层模型,到展示-逻辑-数据(所谓的MVC)三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型,不同层次 表明系统内部设计的精细程度,因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。尤其是对于powser/Server架构模式的MIS类 系统,这种层次更为常见。另外,用户相对于机器来说对系统提供的能力是有个人喜好要求的,不仅要求系统能提供支撑,而且还要更加稳定的、更方便的、灵活 的、快速的等提供,这就需要在架构设计说明书中增加所谓非功能性的设计,即需要描述系统的性能、高可用、可扩展性、可维护、安全性、可移植性等。

系统如何面向外部系统提供交互能力:这一点是要把系统当成一个完整的整体,阐述它如何与外部的系统发生调用关系,外部系统为它提供了哪些开放接口, 它又为外部系统提供了哪些外部接口和能力,同时,在这种相互的调用关系中它处于整个IT架构的何种位置,这其实就是在说系统的整体架构。另外,如果我们把 操作系统和硬件服务器也当成一类特殊的外部系统的话,就需要说明系统如何基于操作系统利用硬件服务器来提供计算、存储、网络等能力,系统如何把自己拆分成 不同的部分以便部署在服务器上,这其实说的是部署架构。

如何面向企业数据提供处理能力:信息系统的原始驱动力就是人们需要借助计算机的强大计算能力来辅助处理大量数据,从而形成可理解的信息,并最终形成 可掌握的知识。因此数据处理是系统的根本目的,至关重要,在架构设计说明书中需要单独描述系统对数据的处理能力,即我们所谓的系统数据架构。这还是可以从 对外和对内两个角度来看,对外即需要说明本系统处理的数据在整个企业数据流中所处的位置,与相关的上下游数据之间的关系,本系统需要从数据上游的外部系统 获取哪些数据?又需要为数据下游的系统提供哪些数据;对内需要说明本系统根据业务需求设计了哪些关键数据表,它们之间是何种主外键关系,是否需要从外部导 入数据为系统做数据初始化等。当然还有对数据管理的描述,包括如何做数据冗余设计,备份机制,数据安全管理机制等。

好,分析完这三种能力,我们几乎就找出了架构设计说明书中应该包括的内容,包括整体架构、逻辑架构、数据架构、部署架构、内外部接口、非功能性设计 等,如果纯把架构设计作为理论研究,有这些也就够了。但是现实中我们编制架构设计说明书毕竟是用来指导我们后续系统开发的,是需要真正落地实施的,因此就 会涉及使用何种技术实现?有哪些关键技术?用到了何种成熟或开源技术组件?复用了哪些之前的技术成果?等等,同时也包括对技术风险的考虑与预防措施。所有 这些就是技术架构的内容。

综上,我们就可以得到一份完整的架构设计说明书的结构及应该包含的内容,其大致章节应该是这样的:

文档概述:包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节;

整体架构:主要从整个IT层描述系统所处的位置,与周边关联系统之间的调用关系;

逻辑架构:系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述;

接口设计:包括系统间的接口设计以及内部功能模块之间的接口设计;

数据架构:本系统与上下游系统间的数据流关系,以及本系统关键数据表设计、数据管理策略等;

技术架构:实施此架构需要用到哪些技术能力,有哪些复用能力及风险;

部署架构:系统如何部署,网络拓扑上有何要求,对硬件服务器有何要求,需要几台,是否需要优化服务器参数;

非功能性设计:性能、高可用、可扩展性、可维护、安全性、可移植性等。

其他说明:如特别约束条件、风险考虑、进度要求、政策限制、环境影响等;

以上,便是我认为一份较为完整的架构设计说明书应该包括的内容了。

时间: 2024-10-12 20:36:54

架构设计之如何写架构设计说明书的相关文章

架构设计三部曲之如何写架构设计说明书

架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键.编制架构设计说明书是开发人员向架构师转变必定会经历的过程.在架构师整个的成长过程中,必定会经历编制架构设计说明书.评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程.作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括<架构设计三部曲之如何写架构设计说明书>.<架构设计三部曲之如何评审架构设计说明书>以及<架构设计三部曲之如何做架构设计>,一来可以帮助自己整理思路,重新审视架

架构设计之如何评审架构设计说明书

自从5月8号写完架构设计三部曲的第一部如何写架构设计说明书,到现在快20多天了,这段时间主要准备了下系统分析师的考试,当然还有各种工作上的 杂事,于是也就拖到现在写第二部如何评审架构设计说明书.当然这个是从评审的角度来看的,其实从编制架构设计说明书的角度来看,也可以阐述具体如何编写架 构设计说明书,就像高考作文一样,评审总是有些采分点的嘛,那么对于编制架构设计说明书来说,哪些是我们应该准备的采分点呢?我们在编制的过程中需要重点 注意哪些章节的哪些内容呢?这就是我接下来想和大家分享的. 根据第一部

领域驱动设计的面向服务架构

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列

.NET应用架构设计—重新认识分层架构(现代企业级应用分层架构核心设计要素)

阅读目录: 1.背景介绍 2.简要回顾下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,很好的隔离静态数据) 4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型 5.两种独立业务层职责设计方法(可以根据具体业务要求来搭

.NET应用架构设计—再次了解分层架构(现代企业应用分层架构核心设计元素)

阅读文件夹: 1.背景介绍 2.简要回想下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,非常好的隔离静态数据) 4.服务层作为SOA契约发布后DTO与业务层的DomainModel共用主要的原子类型 5.两种独立业务层职责设计方法(能够依据详细业务要求

软件架构设计学习总结(22):软件架构——分层架构、事件驱动架构、微内核架构、微服务架构、基于空间的架构

分层架构 (Layered Architecture) 分层架构是最常见的架构,也被称为n层架构.多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师.开发者和软件设计者所熟知.比如MVC. 分层架构的一个特性就是 关注分离(separation of concerns) .在层中的组件只负责本层的逻辑.组件的划分很容易让它们实现自己的角色和职责,也比较容易地开发,测试管理和维护. 我们需要这样的冗余,即使业务层没有处理业务规则,也要通过业务层来调用数

架构搭建----基于DDD领域驱动设计的WCF+EF+WPF分层框架(2)

写在最前面:转载请注明出处 目录置顶: 关于项目--------------------基于DDD领域驱动设计的WCF+EF+WPF分层框架(1) 架构搭建--------------------基于DDD领域驱动设计的WCF+EF+WPF分层框架(2) WCF服务端具体实现---------基于DDD领域驱动设计的WCF+EF+WPF分层框架(3) WCF客户端配置以及代理-----基于DDD领域驱动设计的WCF+EF+WPF分层框架(4) Domain具体实现------------基于DD

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店

一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网

MySQL性能调优与架构设计——第13章 可扩展性设计之 MySQL Replication

第13章 可扩展性设计之 MySQL Replication 前言: MySQL Replication 是 MySQL 非常有特色的一个功能,他能够将一个 MySQL Server 的 Instance 中的数据完整的复制到另外一个 MySQL Server 的 Instance 中.虽然复制过程并不是实时而是异步进行的,但是由于其高效的性能设计,延时非常之少.MySQL 的Replication 功能在实际应用场景中被非常广泛的用于保证系统数据的安全性和系统可扩展设计中.本章将专门针对如何利