程序员必读之软件架构

书籍：https://book.douban.com/subject/26248182/

架构设计

下至接口设计

上至技术选型

架构PPT少不了对ROI（投资回报）和TCO（总体拥有成本）陈述

架构的种类

不管你是构建软件系统、网络还是数据库，任何成功的方案都需要你理解问题。

• 并且设定一个愿景可以和每一个参与构建最终产品的人沟通。

不管何种领域的架构，主要就是结构和愿景。

软件架构是什么

应用程序架构:

应用程序的关注点是应用程序

谈论的是软件设计的低级别切面，通常只考虑单一技术栈

结构单元主要以软件为基础，包括编程语言和结构、类库、框架、API等，由类、组件、模块、函数、设计模式等加以描述

应用程序架构着重考虑软件和代码组织

系统架构：

可以看做是更大规模的应用程序架构

大多数软件系统是由横跨不同层次和技术的多个应用程序组成，每个部分都有自己的应用程序架构

• 要让整个软件系统工作起来，要思考如何组合这些单独的应用程序

大多数软件系统不是孤立的，系统架构要关注互操作性与环境中其他系统的集成

架构单元是各种软硬件，从编程语言和软件框架到服务器和基础设施

系统架构描述为从组件和服务到子系统等更高层次的抽象

系统架构的定义大多数包括软件和硬件

软件架构

是应用程序和系统架构的结合

从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构

开发者的角度会考虑软件开发，关注点多数会放在代码上

还需要有人考虑以下事情：

横切关注点，比如登录和异常处理

安全性，包括认证，授权，和敏感数据保密

性能，可伸缩性、可用性和其他质量属性

审计及其他监管需求

客观环境的约束

互操作性、与其他系统的集成

运营、支持和维护的需求

结构和整个代码库解决问题、实现特性的方法的一致性

评估正在构建的基础有助于交付按计划进行

敏捷的软件架构是什么

不同的软件架构提供不同层次的敏捷

理解组织或业务的变化很重要，因为这能帮助你决定采用何种架构风格,可能是整体架构、微服务架构或者介于两种之间

架构对上设计

所有的架构都是设计，但是并非所有的设计都是架构

架构反应了一个 系统成型的重要设计决策，而重要性则通过改变的成本来衡量

架构的定义提供了一个基准，去思考软件系统中哪些可能是重要的，可能包括:

• 系统的形态(客户端-服务器、基于Web、原生移动客户端、分布式、异步)
• 软件系统的机构(组件、层、交互)
• 技术选择 (编程语言、部署平台)
• 框架选择(Web MVC框架、持久性/ORM框架)
• 设计方法/设计模式 (针对性能、可伸缩性、可用性等)

软件系统架构流程的一部分是搞清楚哪些是重要的以及为什么

软件架构重要吗

成功的软件项目不仅仅是好的代码，有时候要暂时跳出代码，总览大局。

软件架构的好处:

让团队跟随一个清晰的愿景和路线图，无论这个愿景上一人所有还是整个团队所有

技术领导力和更好的协调

与人交流的刺激因素，以便回答与重要决策、非功能需求、限制和其他横切关注点相关的问题

识别和减轻风险的关键

方法和标准的一致性，随之而来的结构良好的代码库

正在构建的产品的坚实基础

对不同的听众，以不同层次的抽象来解决方案的结构

每个软件项目都应该考虑多种因素,以评估必须多少软件架构的思考

软件架构的角色

构成软件架构角色应有的内容:

• 架构驱动力 理解目标，抓住，提炼，挑战需求和限制
• 设计软件 建立技术路线，远景和路线图
• 技术风险 发现、减轻和承担技术风险，保证架构的运转
• 架构演化 贯穿这个软件交付过程，持续的技术领导和对架构的承担
• 编写代码 参与到软件交付的实践部分
• 质量保证 引入并坚持标准、指导、原则等

架构驱动力：

非功能性需求和限制往往对软件架构有影响

设计软件：

需要花时间解决利益相关者提出的问题

软件设计的一个关键部分是技术选择

技术风险：

技术选择就是风险管理，当复杂度和不确定性高的时候降低风险，有利可图时再冒点险

技术决策需要评估和评审，包括一个软件系统的主要结构单元，下至开发过程中引入的库和框架

架构师要主动发现、减轻和承担高优先级的技术风险

架构演化:

软件在这个交付过程中依据不断变化的需求和团队反馈来对其进行演化

架构师要在整个交付过程拥有和演化这个架构

编写代码：

软件架构不一定只涉足日常的编码任务，但要持续地参与到交付中，积极的帮助引导和塑造它

一个大型项目意味着要照看大局，可能没有时间写代码

一个写代码的架构师更有成效，更快乐

质量保证:

最好的架构，糟糕的交付也能让原本成功的软件项目有失败

只要是架构上显著的、业务上关键的、复杂的和高度可见的，都是一个项目的重要组成部分

需要务实的认识到不能保证每件事

软件架构师要懂技术，样他们至少能回答以下问题:

该方案是否有效

我们要这样构建吗

技术面宽对软件架构很要，他们要能回答以下问题:

和其他可选技术相比，我们所选的是否最合适

对该系统的设计和构建，还有哪些选择

是否应该采用一种通用的架构模式

我们是否明白所做决策的利弊

我们照顾到了品质属性的需求吗

如何证明这种架构行之有效

小心鸿沟

如果是软件架构师:

包容与合作：

• 让开发团队参与软件架构的过程，帮助他们了解大局，认同你的决策

动手 如何可能：

• 参与日常开发工作提高对架构交付的理解，或者通过其他方式了解底层进展，如协助设计和代码评审

如果是软件开发者:

了解大觉

挑战架构决策

申请参与

设计软件

软件架构讨论的是重要的设计决策，重要性以变动的成本衡量

早点理解需求、约束和原则，有助于避免将来昂贵的返工

质量属性:

学习领域内常用的质量属性，在开始构建一个新系或者修改已有系统时，先关注这些常用的质量属性

处理非功能需求:

捕捉

提炼

探索需求，搞清楚驱动力是什么？

我们的目标是获取一组特定的，理论上可以明确量化的非功能性要求，比如:

系统平均支持多少斌并发用户? 高峰时段呢?

多长的响应时间是可以接受的?

原则

开发原则：

编码标准和规范

自动化单元测试

静态分析工具

架构原则：

分层策略

业务逻辑的位置

高内聚、低耦合、SOLID

无状态组件

存储过程

域模型：丰富与贫瘠

HTTP会话的使用

始终一致与最终一致

原则通常是因为好的理由才引入，并不是任何时候都有好处。

构建软件的大小和复杂度，加上环境的约束，会帮助你采用哪些原则。

倾听团队成员的反馈会帮助你认清你的原则是否奏效。

技术不是实现细节

你有复杂的非功能性要求吗

大多数软件系统可以用几乎任何技术构建，如果有复杂的非功能性要求。

• 比如高性能和可伸缩性，事情会变得棘手，必须清楚技术、架构的选择是否管用

你有约束吗?

对于构建软件可采用的技术和可选的技能(人)，很多组织都有约束

可以采用各种手段挑战约束，但不能忽视，否则就会交付一个无法与组织已有的IT系统环境集成的软件系统的风险

你有一致性吗?

缺乏一致性的方法会导致代码库难以理解，维护和增强，增加单独可移动部件的数量也会让部署、运营和支持变得复杂