软件架构系列感想(六)

1、代码不会讲述完整的故事。

编写好的代码很重要,重构迫使我们考虑让方法变得更小、更可复用和自文档化,每个人都应该追求编写易于阅读、理解和维护的好代码。

了解系统的设计意图,可以通过代码库如何被拆分为子项目、目录、包、命名空间等对整体架构做出一些判断,也可以根据对这个项目有限的了解、业务领域、你对团队如何构建软件的期望以及你对所用技术的知识,做出自己的假设。

(1)软件系统如何融入已有的系统形态

(2)为什么会选择正在使用的技术

(3)软件系统的整体结构

(4)各个组件在运行时部署在哪里,如何相互沟通

(5)Web层如何知道在哪里找到中间层

(6)日志/配置/错误的处理/其他采用了什么方法,在代码库中是否一致

(7)代码库中是否使用了通用的模式和原则

(8)如何添加新功能,在哪里添加

(9)栈的安全性是如何实现的

(10)如何实现可伸缩性

(11)与其他系统的接口如何工作

2、代码之上还有一个额外的信息层。

这类信息和代码是互补的,应该在某处被捕获,比如轻量级的辅助文档,他能描述代码自己无法描述的东西。

语境:这都是关于什么的

功能概览:系统能做什么

质量属性:是否有重要的非功能需求

约束:是否有重要的约束

原则:采用了哪些设计和开发原则

软件架构:大局看起来怎么样?系统的结构如何

外部接口:有哪些外部接口

代码:是否有你需要解释的实现细节

数据:数据模型看起来怎么样?存储在哪里

基础设施架构:目标部署环境看起来怎么样

部署:软件和基础设施之间的映射是什么样的

运营和支持:人们如何运营和支持系统

3、语境是用来为文档的其余部分设置好场景,涉及以下问题:

(1)这个软件项目/产品/系统是关于什么的

(2)构建的是什么

(3)他如何融入现有环境?比如系统、业务流程等

(4)谁在使用(用户、角色、参与者、人物等)

4、软件的功能性概览,涉及以下问题:

(1)系统实际上做什么是否清楚

(2)哪些特性、功能、用例、用户故事等对架构是重要的,原因是否清楚

(3)重要的用户是谁(角色、参与者、人物等)以及系统如何满足他们的需求是否清楚

(4)上述已用于塑造和定义架构是否清楚

(5)从流程的角度系统做什么是否清楚

(6)系统的主要流程和信息流是什么

5、质量属性,涉及以下问题:

(1)对于架构必须满足的质量属性是否有清晰的认识

(2)质量属性是否满足SMART原则(具体、可衡量、可达成、相关、及时)

(3)有没有不切实际的质量属性

清单:性能(比如延迟和吞吐);可伸缩性(比如数据和流量);可用性(比如运行时间、停机时间、定期维护、全天候、99.9%等);安全性(比如认证、授权、数据保密性等);可扩展性;灵活性;审计;监测和管理;可依赖性;故障转移/灾难恢复目标;业务连续性;互操作性;可访问性;易用性;

6、约束清单:

时间、预算和资源;允许使用的技术清单和技术约束;目标部署平台;已有系统和继承标准;局部标准(比如开发、编码等);公共标准(比如http、soap、xml等);标准协议;标准消息格式;软件开发团队的规模;软件开发团队的技能配置;所构建软件的本质(比如战术或战略);内部知识产权的使用;

7、软件开发原则清单:

架构分层策略;

视图中没有业务逻辑;

视图中没有数据访问;

接口的使用;

始终使用ORM;

依赖注入;

好莱坞原则;

高内聚、低耦合;

遵循SOLID(单一职责原则、开闭原则、里氏替换原则、接口隔离原则、依赖倒置原则);

确保所有组件都是无状态的;

始终选择存储过程;

绝不使用存储过程;

不要重新发明轮子;

错误处理、日志等的通用方法;

购买而非构建;

8、外部接口清单:

(1)关键的外部接口是哪些?

你的系统和其他系统之间的;暴露出来用于消费的API;从你的系统导出的文件;

(2)每个接口都从技术角度考虑过了吗?

接口的技术定义是什么;

如果使用了消息,哪些队列(点对点)和话题(发布-订阅)是用于通信的组件;

消息的格式是什么;

同步还是异步;

异步消息的连接有保障吗;

如果必要,人们会长期订阅吗;

消息能否打乱顺序接收,这是一个问题吗;

接口是否幂等;

接口是否总是可用,或者是否需要在本地缓存数据;

性能/可伸缩性/安全性是如何满足的。

9、数据部分的目的是记录任何从数据的角度来看重要的东西,涉及以下问题:

数据模型看起来是什么样的;

数据存储在哪里;

谁拥有数据;

数据需要多少存储空间;

归档和备份策略是什么;

业务数据的长期归档是否有法规要求;

日志文件和审计跟踪是否有类似的要求;

是否用简单文件来存储;

如果是,用的是哪种格式。

10、基础设施架构,涉及以下问题:

是否有清晰的物理架构;

在所有的层中,什么硬件(虚拟或物理)做了这件事;

如果适用,它是否满足冗余、故障转移和灾难恢复;

选择的硬件组件如何改变大小和被选中是否清楚;

如果使用了多个服务器和网站,他们之间的网络联系是什么;

谁负责基础设施的支持和维护;

有照管通用基础架构(比如数据库、消息总线、应用程序服务器、网络、路由器、交换机、负载均衡器、反向代理、互联网连接等)的中心团队吗;

谁拥有资源;

开发、测试、验收、试制、生产等是否有合适的环境;

11、部署部分就是软件和基础设施之间的映射,涉及以下问题:

软件安装和配置软件在哪里,怎么做;

软件如何部署到基础设施架构部分描述的基础设施元素上是否清楚;

内存和CPU在运行于单块基础设施上的进程间如何分配是否清楚;

有容器和或组件以主动-主动、主动-被动、热备用、冷备用用等形态运行吗;

部署和回滚策略是否已经定义;

软件或基础设施出现故障时会发生什么;

跨站点的数据如何复制是否清楚;

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值