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

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

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

  1. 系统如何面向最终用户提供支撑能力:这一点是要从系统自身的能力来看,即本系统到底应该具备哪些功能,各功能间如何协作以满足支撑最终用户的使用,其实就是要讲系统的功能架构或逻辑架构,回答系统从功能粒度上划分了几个功能模块或子系统,各模块或子系统之间的内部接口关系如何等问题。当然还有一个需要考虑的问题,在纵向维度上,随着架构设计理念的不断发展, 逻辑架构模型从最初的展示-数据两层模型,到展示-逻辑-数据(所谓的MVC)三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型,不同层次表明系统内部设计的精细程度,因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。尤其是对于Browser/Server架构模式的MIS类系统,这种层次更为常见。另外,用户相对于机器来说对系统提供的能力是有个人喜好要求的,不仅要求系统能提供支撑,而且还要更加稳定的、更方便的、灵活的、快速的等提供,这就需要在架构设计说明书中增加所谓非功能性的设计,即需要描述系统的性能、高可用、可扩展性、可维护、安全性、可移植性等。
  2. 系统如何面向外部系统提供交互能力:这一点是要把系统当成一个完整的整体,阐述它如何与外部的系统发生调用关系,外部系统为它提供了哪些开放接口,它又为外部系统提供了哪些外部接口和能力,同时,在这种相互的调用关系中它处于整个IT架构的何种位置,这其实就是在说系统的整体架构。另外,如果我们把操作系统和硬件服务器也当成一类特殊的外部系统的话,就需要说明系统如何基于操作系统利用硬件服务器来提供计算、存储、网络等能力,系统如何把自己拆分成不同的部分以便部署在服务器上,这其实说的是部署架构
  3. 如何面向企业数据提供处理能力:信息系统的原始驱动力就是人们需要借助计算机的强大计算能力来辅助处理大量数据,从而形成可理解的信息,并最终形成可掌握的知识。因此数据处理是系统的根本目的,至关重要,在架构设计说明书中需要单独描述系统对数据的处理能力,即我们所谓的系统数据架构。这还是可以从对外和对内两个角度来看,对外即需要说明本系统处理的数据在整个企业数据流中所处的位置,与相关的上下游数据之间的关系,本系统需要从数据上游的外部系统获取哪些数据?又需要为数据下游的系统提供哪些数据;对内需要说明本系统根据业务需求设计了哪些关键数据表,它们之间是何种主外键关系,是否需要从外部导入数据为系统做数据初始化等。当然还有对数据管理的描述,包括如何做数据冗余设计,备份机制,数据安全管理机制等。

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

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

    1. 文档概述:包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节;
    2. 整体架构:主要从整个IT层描述系统所处的位置,与周边关联系统之间的调用关系;
    3. 逻辑架构:系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述;
    4. 接口设计:包括系统间的接口设计以及内部功能模块之间的接口设计;
    5. 数据架构:本系统与上下游系统间的数据流关系,以及本系统关键数据表设计、数据管理策略等;
    6. 技术架构:实施此架构需要用到哪些技术能力,有哪些复用能力及风险;
    7. 部署架构:系统如何部署,网络拓扑上有何要求,对硬件服务器有何要求,需要几台,是否需要优化服务器参数;
    8. 非功能性设计:性能、高可用、可扩展性、可维护、安全性、可移植性等。
    9. 其他说明:如特别约束条件、风险考虑、进度要求、政策限制、环境影响等;

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

来自为知笔记(Wiz)

时间: 2024-10-13 19:56:56

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

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

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

架构设计三部曲之如何做架构设计

架构设计不是架构师的专属工作,对非技术人员甚至是开发人员来说,从实实在在的需求到高神莫测的架构设计仿佛是一个神秘的过程,只有具有架构师头衔的人才能掌握各中玄妙,这篇文章就是从最基本的事物关系来回答如何根据需求进行架构设计的问题. 根据我前面的文章,架构的本质是事物与事物之间恰当的关系,不同领域的架构,其事物的指代不同,比如对于组织架构而言,事物指的是人与机构:建筑架构,事物指的是钢筋混凝土与空间.那在软件领域,事物指的是什么呢?我们知道,软件系统的本质是人类将自身无法处理的大量业务相关的数据进行

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

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

Android App的设计架构:MVC,MVP,MVVM与架构经验谈

来源: Android App的设计架构:MVC,MVP,MVVM与架构经验谈 和MVC框架模式一样,Model模型处理数据代码不变在Android的App开发中,很多人经常会头疼于App的架构如何设计: 我的App需要应用这些设计架构吗? MVC,MVP等架构讲的是什么?区别是什么? 本文就来带你分析一下这几个架构的特性,优缺点,以及App架构设计中应该注意的问题. 1.架构设计的目的 通过设计使程序模块化,做到模块内部的高聚合和模块之间的低耦合.这样做的好处是使得程序在开发的过程中,开发人员

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

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

iOS应用架构谈(一):架构设计的方法论

当我们讨论客户端应用架构的时候,我们在讨论什么? 其实市面上大部分应用不外乎就是颠过来倒过去地做以下这些事情: 简单来说就是调API,展示页面,然后跳转到别的地方再调API,再展示页面. 那这有什么好架构的? 非也,非也. ---- 包不同 <天龙八部> App确实就是主要做这些事情,但是支撑这些事情的基础,就是做架构要考虑的事情: 调用网络API.如何让业务开发工程师方便安全地调用网络API?然后尽可能保证用户在各种网络环境下都能有良好的体验? 页面展示.页面如何组织,才能尽可能降低业务方代

MMORGP大型游戏设计与开发(客户端架构 part1 of vegine)

重写有些核心接口的时候,其实遇到了许多的问题,甚至一度的想过要放弃,但是最终还是坚持了下来.在客户端提供的这些接口中,可以清晰的看到客户端所依赖的各种模块的支持,以及各自之间的一些关联.下面只是介绍了vengine(微引擎)接口的基础模块框架,所谓的接口即对象设计中常见的Interface,为一个框架提供了清晰的规范支持. VEGINE FRAMEWORK 功能实现 该接口已全部实现,具体的实例只需要继承接口封装即可.上图只为简单的模块介绍,其实每个接口都有每个接口其特别的用处,这一点会在接下的

Atitit.架构设计趋势 设计模式 ---微服务架构&#160;&#160;soa

Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些设计 断路器 幂等2 <微服务设计>([英] 纽曼(Sam Newman))3 微服务架构与实践4 什么是微服务架构? Martin Fowler认为,微服务架构是一种独立部署的软件应用设计方式.这种架构方式没有准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上有着共性.

软件架构设计:程序员向架构师转型必备(第二版) 笔记

1 从程序员到架构师 1 1.1 软件业人才结构 1.1.1 金字塔型还是橄榄型? 1 1. 橄榄型:中间大两头小:   2. 区分开学历结构和能力结构:学历结构:橄榄型,能力结构:金字塔型: 1.1.2 从程序员向架构师转型 2 1. 软企该怎么做? 2 解析软件架构概念 10 1. 架构的概念很多种,不统一: 2.1 软件架构概念的分类 11 1. 架构的概念很难统一: 2. 本书将概念分为组成派和决策派两大流派,来帮助理解: 2.1.1 组成派 11 1. 软件系统的架构将系统描述为计算组