软件架构–架构设计的整体介绍

• 1 介绍
• • 1.1 概述
  • 1.2 复杂系统
  • 1.3 架构目标
  • 1.4 架构过程（引用《系统架构：复杂系统的产品设计与开发》）
  • 1.5 系统预测方式
  • • 经验
    • 实验
    • 建模
    • 推理
  • 1.6 设计工具
  • • UML
  • 1.7 架构师分类与能力要求
  • • 微软架构师分类
    • 《职业成长的逻辑模型》对架构师的能力要求
  • 1.8 需求分析
  • • 利益分析
    • 资源评估
    • 需求规范
  • 1.9 架构层级
  • 1.10 软件架构的发展史
  • 1.11 ?软件工程师的职业发展方向
• 2 架构分析
• • 2.1 分类
  • 2.2 设计规范
  • • GRASP 9大原则
    • • 信息专家（Information Expert）
      • 创建者（Creator）
      • 低耦合（Low coupling）
      • 高内聚（High Cohesion）
      • 控制器（Controller）
      • 多态性（Polymorphism）
      • 纯虚构（Pure Fabrication）
      • 间接性（Indirection）
      • 防止变异（Protected Variations）
    • SOLID 6大原则
    • • 单一职责原则（Single Responsibility Principle）
      • 开闭原则（Open Closed Principle）
      • 里氏替换原则（Liskov Substitution Principle）
      • 迪米特法则（Law of Demeter）
      • 接口隔离原则（Interface Segregation Principle）
      • 依赖倒置原则（Dependence Inversion Principle）
    • GOF 23种设计模式
    • • 创建型模式
      • 结构型模式
      • 行为型模式
• 参考

1 介绍

1.1 概述

• 架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。
• 难懂的事物是具备较高的表面复杂度，超出人类的理解能力。如今 会的告诉发展，很多系统复杂度在快速增加。
• 好的系统架构，具备必要的复杂度同时又不难懂。

1.2 复杂系统

• 人体系统、生态系统、大气系统、水源系统
• 机械系统、电子系统、操作系统、 会系统、航天平台系统、汽车控制系统、石油平台系统

1.3 架构目标

• 软件架构最核心的问题是解决复杂性的问题，并且在解决问题的过程中，在时间（项目周期、行业发展速度）和空间（开发资源、护城河）上找到最佳的平衡点。
• 架构师眼里第一件事不是多流行的技术，多高性能的框架，或者多完善的业务模型，而应该聚焦在利益（活着并且活得好）之上。

1.4 架构过程（引用《系统架构：复杂系统的产品设计与开发》）

第一项任务：确定系统及其形式与功能。
第二项任务：确定系统中的实体、实体的形式与功能，以及系统边界和系统所处的环境。
第三项任务：确定实体之间的关系。
第四项任务：基于实体的功能以及实体之间的功能互动，来确定系统的涌现属性。

1.5 系统预测方式

经验

实验

建模

推理

1.6 设计工具

UML

利益分析

• 公司利益、客户利益、团队利益会在系统构建中交织在一起。
• 以公司的利益为本，客户利益为目标，最大程度去兼顾团队利益。
• 定好原则，不忘初心。

资源评估

资源评估对项目经理来说很重要，资源是项目进度的支撑；
资源评估对架构师来说也很重要，资源是架构实现的支撑；

需求规范

系统的功能来自客户的需求，这二者如果出现歧义，架构师需要去消除。

• 需求是什么li>
• 需求的价值好客户公司/li>
• 需求的代价户付出付出/li>
• 需求的紧迫性li>

1.9 架构层级

1.11 ?软件工程师的职业发展方向

我们设计对象(类)的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。
eg： 常见的 上商店的购物车（ShopCar），需要让每种商品（SKU）只在购物车内出现一次，购买相同商品，只需要更新商品的数量即可。

低耦合（Low coupling）

低耦合模式的意思就是要我们尽可能地减少类之间的连接。
其作用非常重要：
a、低耦合降低了因一个类的变化而影响其他类的范围。
b、低耦合使用类更容易理解，因为类会变得简单，更内聚。
下面这些情况会造成类 A、B 之间的耦合：
a、A 是 B 的属性
b、A 调用 B 的实例的方法
c、A 的方法中引用的 B，例如 B 是 A 方法的返回值或参数。
d、A 是 B 的子类，或者 A 实现 B
关于低耦合，还有下面一些基本原则：
a、Don’t Talk to Strangers 原则
意思就是说，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题，不连接就一了百了了。
b、如果 A 已经和 B 有连接，如果分配 A 的职责给 B 不合适的话（违反信息专家模式），那么就把 B 的职责分配给 A。
c、两个不同模块的内部类之间不能连接，否则比招 应！
eg：Creator 模式的例子里，实际业务中需要另一个出货人来清点订单（Order）上的商品（SKU），并计算出商品的总价，但是由于订单和商品之间的耦合已经存在了，那么把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。如下图：

控制器（Controller）

用来接受和处理系统事件的职责，一般应该分配给一个能够代表整个系统的类，这样的类通常被命名为“XX处理器”、“XX协调器”或“XX会话”。
关于控制器类，有如下原则：
a、系统事件的接收与处理通常由一个高级类来代替。
b、一个子系统会有很多控制类，分别处理不同的事务。

多态性（Polymorphism）

这里的多态跟 OO 三大基本特征之一的“多态”是一个意思。
eg：我们想设计一个绘画程序，要支持可以画不同类型的图形，我们定义一个抽象类 Shape，矩形（Rectangle）、圆形（Round）分别继承这个抽象类，并重写（override）Shape 类里的Draw() 方法，这样我们就可以使用同样的接口（Shape抽象类）绘制出不同的图形，如下图：

间接性（Indirection）

“间接”顾名思义，就是这个事不能直接来办，需要绕个弯才行。绕个弯的好处就是，本来直接会连接在一起的对象彼此隔离开了，一个变动不会影响另一个。就像我在前面的低耦合模式里说的一样，“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块，这样对于这两个模块来说，他们之间仍然是没有耦合/依赖关系的。

防止变异（Protected Variations）

预先找出不稳定的变化点，使用统一的接口封装起来，如果未来发生变化的时候，可以通过接口扩展新的功能，而不需要去修改原来旧的实现。也可以把这个模式理解为 OCP（开闭原则），就是说一个软件实体应当对拓展开发，对修改关闭。在设计一个模块的时候，要保证这个模块可以在不需要被修改的前提下可以得到拓展。这样做的好处就是通过拓展给系统提供了新的职责，以满足新的需求，同时又没有改变系统原来的功能。

SOLID 6大原则

• Single Responsibility Principle：单一职责原则
• Open Closed Principle：开闭原则
• Liskov Substitution Principle：里氏替换原则
• Law of Demeter：迪米特法则
• Interface Segregation Principle：接口隔离原则
• Dependence Inversion Principle：依赖倒置原则
  把这六个原则的首字母联合起来（两个 L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。

单一职责原则（Single Responsibility Principle）

There should never be more than one reason for a class to change.
一个类更改的原因不应该超过一个。
eg：参考下图中的设计，图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。

开闭原则（Open Closed Principle）

Software entities like classes, modules and functions should be open for extension but closed for modification.
一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。
eg：如下图，有一个客户端程序通过数据访问接口操作数据，对于这套系统来说，一开始计划使用的是SQL Server或Oracle数据库，但是后来考虑到成本，改用免费的mysql；那么对于客户端程序来说，后来数据的扩展对它没有任何影响，它在不知不觉间就用上了免费好用的MySQL数据库，这全要感谢OCP原则。

GOF 23种设计模式

GoF 23种设计模式一般分为三大类。

创建型模式

创建型模式，就是创建对象的模式，抽象了实例化的过程。
它帮助一个系统独立于如何创建、组合和表示它的那些对象。
关注的是对象的创建，创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关心创建对象过程中的逻辑

• 工厂方法模式(Factory Method)
• 抽象工厂模式(Abstract Factory)
• 单例模式(Singleton)
• 创建者模式(Builder)
• 原型模式(Prototype)

结构型模式

结构型模式是为解决怎样组装现有的类，设计他们的交互方式，从而达到实现一定的功能的目的。
结构型模式包容了对很多问题的解决。例如：扩展性（外观、组成、代理、装饰）封装性（适配器，桥接）。

• 适配器模式(Adapter)
• 外观模式(Facade)
• 享元模式(Flyweight)
• 组合模式(Composite)
• 装饰器模式(Decorator)
• 代理模式(Proxy)
• 桥接模式(Bridge)

行为型模式

行为型模式涉及到算法和对象间职责的分配。
行为模式描述了对象和类的模式，以及它们之间的通信模式。
行为型模式刻划了在程序运行时难以跟踪的复杂的控制流可分为行为类模式和行为对象模式

• 策略模式(Strategy)
• 状态模式(State)
• 职责链模式(Chain of Responsibility)
• 观察者模式(Observer)
• 模板方法模式(Template Method)
• 命令模式(Command)
• 备忘录模式(Memento)
• 迭代器模式(Iterator)
• 调停者模式(Mediator)
• 解释器模式(Interpreter)
• 访问者模式(Visitor)

参考

1、
2、林振华–架构设计的本质
3、软件架构–《系统架构：复杂系统的产品设计与开发》笔记
4、UML概述
5、GRASP模式概述
6、GRASP—-（职责分配原则）
7、GRASP 设计原则
8、六大设计原则(SOLID)
9、软件架构–《设计模式–GoF》理解
10、软件架构（software architecture）
11、Software Architecture软件架构是啥
12、架构师之路 — 软件架构 — Overview
13、软考分类精讲-软件架构设计(一)
14、软件岗位–CTO、技术VP、技术总监、首席架构师
15、如何成为更好的软件架构师