软件架构系列感想（六）

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在运行于单块基础设施上的进程间如何分配是否清楚；

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

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

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

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