1134 字
3 分钟
设计模式与架构模式深度解析
一、设计模式概述
设计模式是软件开发中经过验证的解决方案模板。GoF(Gang of Four)将 23 种设计模式分为三大类:
graph TB
subgraph "GoF 设计模式体系"
A["设计模式"] --> B["创建型<br>5 种"]
A --> C["结构型<br>7 种"]
A --> D["行为型<br>11 种"]
B --> B1["单例模式"]
B --> B2["工厂方法"]
B --> B3["抽象工厂"]
B --> B4["建造者"]
B --> B5["原型"]
C --> C1["适配器"]
C --> C2["桥接"]
C --> C3["组合"]
C --> C4["装饰器"]
C --> C5["门面"]
C --> C6["享元"]
C --> C7["代理"]
D --> D1["策略"]
D --> D2["观察者"]
D --> D3["命令"]
D --> D4["迭代器"]
D --> D5["模板方法"]
D --> D6["责任链"]
D --> D7["其他 5 种"]
end
1.1 创建型模式
创建型模式关注对象的创建过程,将对象的创建和使用分离。
classDiagram
class Client {
+useProduct()
}
class Factory {
<<interface>>
+createProduct() Product
}
class ConcreteFactoryA {
+createProduct() ProductA
}
class ConcreteFactoryB {
+createProduct() ProductB
}
class Product {
<<interface>>
+operation()
}
class ProductA {
+operation()
}
class ProductB {
+operation()
}
Client --> Factory
Factory <|.. ConcreteFactoryA
Factory <|.. ConcreteFactoryB
ConcreteFactoryA --> ProductA
ConcreteFactoryB --> ProductB
Product <|.. ProductA
Product <|.. ProductB
| 模式 | 用途 | 场景 | 核心思想 |
|---|---|---|---|
| 单例 | 全局唯一 | 配置、日志 | 私有构造 + 静态实例 |
| 工厂方法 | 对象创建 | 依赖注入 | 子类决定实例化 |
| 抽象工厂 | 产品族创建 | UI 组件 | 相关对象统一创建 |
| 建造者 | 复杂对象构建 | SQL Builder | 分步构建 + 链式调用 |
| 原型 | 对象克隆 | 缓存对象 | 复制而非新建 |
1.2 结构型模式
结构型模式关注类和对象的组合,形成更大的结构。
flowchart TB
subgraph "适配器模式"
A1[客户端] --> A2[目标接口]
A3[适配器] -.->|实现| A2
A4[被适配者] --> A3
end
subgraph "装饰器模式"
B1[组件] --> B2[装饰器基类]
B3[具体装饰器A] -.->|继承| B2
B4[具体装饰器B] -.->|继承| B2
end
subgraph "代理模式"
C1[客户端] --> C2[代理]
C2 --> C3[真实对象]
end
| 模式 | 用途 | 场景 | 核心思想 |
|---|---|---|---|
| 适配器 | 接口转换 | 旧接口兼容 | 包装不兼容接口 |
| 桥接 | 抽象与实现分离 | 多平台支持 | 组合替代继承 |
| 组合 | 树形结构 | 菜单系统 | 统一处理个别与整体 |
| 装饰器 | 动态增强 | 日志、缓存 | 包装器链式叠加 |
| 门面 | 简化接口 | 统一入口 | 提供高层统一接口 |
| 代理 | 间接访问 | 远程调用 | 控制对象访问 |
1.3 行为型模式
行为型模式关注对象之间的通信和职责分配。
sequenceDiagram
participant C as Client
participant S as Context
participant SA as StrategyA
participant SB as StrategyB
C->>S: 设置策略 A
C->>S: 执行操作
S->>SA: algorithm()
SA-->>S: 结果
C->>S: 设置策略 B
C->>S: 执行操作
S->>SB: algorithm()
SB-->>S: 结果
| 模式 | 用途 | 场景 | 核心思想 |
|---|---|---|---|
| 策略 | 算法切换 | 支付方式 | 算法封装可互换 |
| 观察者 | 事件通知 | 消息订阅 | 一对多依赖通知 |
| 命令 | 请求封装 | 撤销重做 | 操作对象化 |
| 迭代器 | 集合遍历 | 数据处理 | 统一遍历接口 |
| 模板方法 | 算法骨架 | 框架扩展 | 固定流程可变步骤 |
| 责任链 | 请求处理 | 过滤器 | 链式传递处理 |
二、SOLID 原则
SOLID 是面向对象设计的五大原则,详见代码设计的原则中的深入讨论。
2.1 五大原则关系
graph TB
subgraph "SOLID 原则体系"
S["单一职责<br>SRP"] --> |"一个类只做一件事"| S1["低耦合"]
O["开闭原则<br>OCP"] --> |"扩展开放 修改关闭"| O1["稳定性"]
L["里氏替换<br>LSP"] --> |"子类可替换父类"| L1["多态安全"]
I["接口隔离<br>ISP"] --> |"接口小而专注"| I1["解耦"]
D["依赖倒置<br>DIP"] --> |"依赖抽象不依赖具体"| D1["灵活性"]
S1 --> G["高内聚低耦合"]
O1 --> G
L1 --> G
I1 --> G
D1 --> G
end
| 原则 | 说明 | 违反表现 | 重构方向 |
|---|---|---|---|
| S | 单一职责 | 类承担过多职责 | 拆分职责 |
| O | 开闭原则 | 修改现有代码 | 抽象扩展点 |
| L | 里氏替换 | 子类违反父类行为 | 规范继承关系 |
| I | 接口隔离 | 接口过于臃肿 | 接口拆分 |
| D | 依赖倒置 | 依赖具体而非抽象 | 依赖注入 |
2.2 实践示例
# 违反 SRP:类承担多个职责class UserManager: def create_user(self, name, email): # 用户创建 pass
def send_email(self, user, message): # 发送邮件 pass
def generate_report(self): # 生成报告 pass
# 符合 SRP:职责分离class UserService: def create_user(self, name, email): pass
class EmailService: def send_email(self, user, message): pass
class ReportService: def generate_report(self): pass# 违反 OCP:新增类型需要修改现有代码class DiscountCalculator: def calculate(self, customer_type, amount): if customer_type == "regular": return amount * 0.9 elif customer_type == "vip": return amount * 0.8 # 新增类型需要修改这里
# 符合 OCP:通过扩展而非修改from abc import ABC, abstractmethod
class DiscountStrategy(ABC): @abstractmethod def calculate(self, amount: float) -> float: pass
class RegularDiscount(DiscountStrategy): def calculate(self, amount: float) -> float: return amount * 0.9
class VIPDiscount(DiscountStrategy): def calculate(self, amount: float) -> float: return amount * 0.8
# 新增类型只需添加新类,无需修改现有代码class SVIPDiscount(DiscountStrategy): def calculate(self, amount: float) -> float: return amount * 0.7三、微服务架构模式
3.1 服务拆分模式
graph TB
subgraph "单体架构"
M["单体应用<br>所有功能一体"]
end
subgraph "微服务架构"
subgraph "按业务能力拆分"
U["用户服务"]
O["订单服务"]
P["支付服务"]
I["库存服务"]
end
subgraph "基础设施"
G["API Gateway"]
R["服务注册"]
C["配置中心"]
MQ["消息队列"]
end
end
M -.->|拆分| U
M -.->|拆分| O
M -.->|拆分| P
M -.->|拆分| I
G --> U
G --> O
G --> P
G --> I
U <--> R
O <--> R
P <--> R
I <--> R
| 拆分策略 | 说明 | 适用场景 | 优缺点 |
|---|---|---|---|
| 按业务能力 | 职责分离 | 业务边界清晰 | 清晰但需协调 |
| 按子域 | DDD 分析 | 复杂业务领域 | 精确但复杂 |
| 按团队 | 康威定律 | 独立团队交付 | 敏捷但可能分散 |
3.2 微服务通信模式
sequenceDiagram
participant C as Client
participant G as API Gateway
participant U as User Service
participant O as Order Service
participant MQ as Message Queue
Note over C,MQ: 同步通信 (REST/gRPC)
C->>G: GET /orders/123
G->>U: 验证用户身份
U-->>G: 用户信息
G->>O: 获取订单详情
O-->>G: 订单数据
G-->>C: 响应
Note over C,MQ: 异步通信 (消息队列)
C->>G: POST /orders
G->>O: 创建订单
O->>MQ: 发布 order.created
MQ->>U: 通知用户服务
MQ->>I: 通知库存服务
# 同步通信:REST/gRPCclass UserService: def __init__(self, http_client): self.http = http_client
def get_order(self, order_id): response = self.http.get(f"/orders/{order_id}") return response.json()
# 异步通信:消息队列class OrderService: def __init__(self, message_queue): self.queue = message_queue
def create_order(self, order): self.queue.publish("order.created", order)3.3 服务发现
# 客户端发现apiVersion: v1kind: Servicemetadata: name: user-servicespec: selector: app: user ports: - port: 80 targetPort: 8080
---
apiVersion: v1kind: Servicemetadata: name: api-gatewayspec: type: NodePort ports: - port: 80 targetPort: 8080四、分层架构模式
4.1 经典三层架构
graph TB
subgraph "三层架构"
subgraph "表现层 Presentation"
P1["Controller"]
P2["REST API"]
P3["GraphQL"]
end
subgraph "业务层 Business"
B1["Service"]
B2["Domain Model"]
B3["Business Logic"]
end
subgraph "数据层 Data"
D1["Repository"]
D2["DAO"]
D3["ORM"]
end
subgraph "基础设施 Infrastructure"
DB[(Database)]
Cache[(Cache)]
MQ[(Message Queue)]
end
end
P1 --> B1
P2 --> B1
P3 --> B1
B1 --> B2
B2 --> B3
B3 --> D1
D1 --> D2
D2 --> D3
D3 --> DB
D3 --> Cache
B3 --> MQ
| 层 | 职责 | 技术示例 | 关注点 |
|---|---|---|---|
| 表现层 | 用户界面交互 | Controller、API | 请求处理 |
| 业务层 | 业务逻辑处理 | Service | 领域逻辑 |
| 数据层 | 数据持久化 | Repository、DAO | 数据存取 |
4.2 六边形架构(端口与适配器)
graph TB
subgraph "六边形架构 Hexagonal Architecture"
subgraph "外部世界"
W1["Web UI"]
W2["Mobile App"]
W3["CLI"]
W4["外部 API"]
end
subgraph "适配器层"
A1["REST Adapter"]
A2["GraphQL Adapter"]
A3["CLI Adapter"]
A4["External API Adapter"]
end
subgraph "端口层"
P1["端口 IN<br>驱动端口"]
P2["端口 OUT<br>被驱动端口"]
end
subgraph "应用核心"
CORE["领域模型<br>业务逻辑<br>用例"]
end
subgraph "基础设施适配器"
IA1["数据库适配器"]
IA2["缓存适配器"]
IA3["消息队列适配器"]
end
end
W1 --> A1
W2 --> A2
W3 --> A3
W4 --> A4
A1 --> P1
A2 --> P1
A3 --> P1
A4 --> P1
P1 --> CORE
CORE --> P2
P2 --> IA1
P2 --> IA2
P2 --> IA3
| 组件 | 说明 | 示例 |
|---|---|---|
| 端口 IN | 驱动端口(API) | 用例接口 |
| 端口 OUT | 被驱动端口(DB) | 仓储接口 |
| 适配器 IN | 接收外部请求 | REST Controller |
| 适配器 OUT | 与外部系统交互 | 数据库实现 |
| 应用核心 | 业务逻辑 | 领域模型 |
4.3 架构对比
graph LR
subgraph "架构演进"
A["三层架构"] --> B["六边形架构"]
B --> C["洋葱架构"]
C --> D["整洁架构"]
end
A -.->|"依赖方向"| E["外层依赖内层"]
B -.->|"依赖倒置"| F["核心独立于框架"]
C -.->|"层次化"| G["领域模型居中"]
D -.->|"统一抽象"| H["关注业务规则"]
五、响应式架构模式
5.1 响应式宣言
graph TB
subgraph "响应式系统特性"
R["响应式<br>Responsive"] --> |"及时响应"| U["用户满意"]
RES["弹性<br>Resilient"] --> |"故障恢复"| U
E["弹性伸缩<br>Elastic"] --> |"资源优化"| U
M["消息驱动<br>Message Driven"] --> |"松耦合"| RES
M --> |"异步非阻塞"| E
M --> |"背压控制"| R
end
# 响应式系统特性class ReactiveSystem: def __init__(self): self.principles = { "responsive": "及时响应用户", "resilient": "故障时仍可响应", "elastic": "负载变化时弹性伸缩", "message_driven": "异步通信松耦合" }5.2 命令查询职责分离(CQRS)
graph TB
subgraph "CQRS 架构"
subgraph "Command Side 写端"
C1["Command"]
C2["Command Handler"]
C3["Aggregate"]
C4["Write Model"]
C5["Event Store"]
end
subgraph "Query Side 读端"
Q1["Query"]
Q2["Query Handler"]
Q3["Read Model"]
Q4["Materialized View"]
end
subgraph "Event Bus"
EB["事件总线"]
end
end
C1 --> C2
C2 --> C3
C3 --> C4
C4 --> C5
C2 --> EB
EB --> Q3
Q3 --> Q4
Q1 --> Q2
Q2 --> Q4
# CQRS 示例class CommandHandler: def handle(self, command): """处理写操作""" if isinstance(command, CreateOrderCommand): return self.create_order(command) elif isinstance(command, UpdateOrderCommand): return self.update_order(command)
class QueryHandler: def handle(self, query): """处理读操作""" if isinstance(query, GetOrderQuery): return self.get_order(query.order_id) elif isinstance(query, ListOrdersQuery): return self.list_orders(query.filters)六、架构选择指南
6.1 架构模式对比
graph TB
subgraph "架构选择决策树"
START["项目复杂度"] --> LOW{"低复杂度?"}
LOW -->|是| MONO["单体架构"]
LOW -->|否| MED{"中等复杂度?"}
MED -->|是| LAYERED["分层架构"]
MED -->|否| HIGH{"高复杂度?"}
HIGH -->|是| DOMAIN{"领域复杂?"}
HIGH -->|否| MICRO["微服务架构"]
DOMAIN -->|是| HEX["六边形架构<br>+ DDD"]
DOMAIN -->|否| MICRO
MONO --> TEAM{"团队规模?"}
LAYERED --> TEAM
HEX --> TEAM
MICRO --> TEAM
TEAM -->|小型| SIMPLE["简单优先"]
TEAM -->|大型| SCALE["考虑扩展性"]
end
6.2 总结对比
| 模式类别 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 设计模式 | 代码层面的可复用方案 | 提高代码质量 | 过度使用复杂化 |
| 分层架构 | 传统 Web 应用 | 结构清晰 | 层间耦合 |
| 微服务架构 | 大规模分布式系统 | 独立部署扩展 | 运维复杂 |
| 六边形架构 | 领域驱动设计 | 业务与技术解耦 | 学习曲线陡 |
| 响应式架构 | 高并发实时系统 | 高性能高可用 | 调试困难 |
架构选择原则:
- 简单优先:先简单后复杂,避免过度设计
- 业务适配:匹配业务复杂度,不盲目追新
- 团队匹配:考虑团队能力,选择合适的架构
- 演进思维:预留扩展空间,支持渐进式演进
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时
相关文章 智能推荐
1
零信任架构
密码学与安全工程 深入零信任架构——零信任原则、BeyondCorp、身份代理、mTLS、服务网格零信任。
2
什么是微服务?
技术科普 微服务架构深度解析——从定义、特征、与单体架构对比,到服务拆分策略、通信机制、治理模式,全面理解微服务的本质。
3
Istio:服务网格的工程实践
分布式系统深入 深入解析 Istio 服务网格——Sidecar 代理、流量管理、安全策略与可观测性的工程实践
4
为什么需要服务网格
技术科普 深入理解服务网格的设计动机,掌握微服务治理的演进历程与核心技术。
5
服务发现:微服务通信的基础设施
分布式系统深入 深入理解服务发现机制——从 DNS 到注册中心,客户端发现与服务端发现的差异与工程实践






