software-patterns

软件模式入门

概述

架构模式用于解决特定的结构性问题。本技能提供一个决策框架，帮助你判断何时应用各个模式，而不是提供一个需要死记硬背的目录。

核心理念： 模式用于解决问题。没有问题？就不需要模式。

何时使用本技能

在以下情况启用：

• 设计新系统或重大功能
• 添加外部服务集成
• 代码变得难以测试或修改
• 服务开始彼此循环调用
• 一个组件发生故障并波及其他组件
• 业务逻辑分散在多个位置

模式层级

基础模式（默认应用）

这些模式为可维护的系统提供结构基础。除非有具体理由不采用，否则都应应用。

模式	解决的问题	应用信号
依赖注入	紧密耦合、无法测试的代码	类自行实例化其依赖项
面向服务的架构	单体结构混乱、边界不明确	业务逻辑分散，没有明确的归属

DI 快速示例——修改前后：

# BEFORE: tight coupling, hard to test
class OrderService:
    def __init__(self):
        self.db = PostgresDatabase()       # concrete dependency
        self.mailer = SmtpMailer()         # concrete dependency

# AFTER: dependencies injected, easily testable
class OrderService:
    def __init__(self, db: Database, mailer: Mailer):
        self.db = db
        self.mailer = mailer
# In tests: OrderService(db=FakeDatabase(), mailer=FakeMailer())

情境模式（出现相应问题时应用）

这些模式用于解决特定问题。不要提前应用。

模式	解决的问题	应用信号
Repository	数据访问耦合	服务了解数据库细节
领域事件	循环依赖、时间耦合	服务 A 调用 B，B 调用 C，C 又调用 A
防腐层	与外部系统耦合	外部 API 变更导致代码出错
熔断器	级联故障	一个响应缓慢的服务拖垮所有服务

→ 基础模式详情 → 情境模式详情

快速决策树

Is code hard to test?
├─ Yes → Apply Dependency Injection
└─ No → Continue

Is business logic scattered?
├─ Yes → Apply Service-Oriented Architecture
└─ No → Continue

Do services know database details?
├─ Yes → Apply Repository Pattern
└─ No → Continue

Do services call each other in cycles?
├─ Yes → Apply Domain Events
└─ No → Continue

Does external API change break your code?
├─ Yes → Apply Anti-Corruption Layer
└─ No → Continue

Does one slow service break everything?
├─ Yes → Apply Circuit Breaker
└─ No → Current patterns sufficient

→ 完整决策树

实施优先级

开始构建新系统时：

1. 首先： 建立 DI 容器／模式
2. 其次： 定义服务边界（SOA）
3. 第三： 为数据访问添加 Repository
4. 然后： 随着问题出现，逐步引入情境模式

重构现有系统时：

1. 首先： 找出具体的痛点
2. 其次： 应用能解决该问题的最精简模式
3. 第三： 验证改进效果后再添加更多模式

导航

模式详情

• 基础模式：DI 和 SOA 实施指南，以及何时偏离这些模式
• 情境模式：Repository、领域事件、ACL 和熔断器详情

决策支持

• 决策树：用于选择模式的完整流程图
• 反模式：常见的错误应用方式及其识别方法
• 代码异味信号：低层次代码异味（大型 switch、嵌套循环、参数重新赋值、高复杂度／高耦合）与其所指示的架构问题及对应解决模式的映射——基于 CAST Highlight _multi 质量指标整理（https://doc.casthighlight.com/）

实施

• 示例：各类模式组合的语言无关伪代码

危险信号——停止

遇到以下情况时，停止：

• “我来一开始就把这些模式都加上” → 只应用能解决当前问题的模式
• “这个模式是最佳实践” → 它针对什么问题才是最佳实践？
• “我们以后可能会需要” → YAGNI——需要时再添加
• “Service Locator 更简单” → 隐藏依赖会带来测试难题
• “我直接调用这个服务就行” → 考虑一下事件是否能更好地解耦
• “外部 API 很稳定，不需要 ACL” → API 迟早都会变更

以上任何一种情况都意味着：停止。先找出具体问题。

与其他技能集成

• test-driven-development：DI 有助于提升可测试性；TDD 可验证模式的应用
• systematic-debugging：清晰的边界（SOA）可简化调试
• root-cause-tracing：结构良好的服务具有更清晰的调用链

模式组合

常见的有效组合：

场景	模式
新建微服务	DI + SOA + Repository
外部 API 集成	DI + ACL + Circuit Breaker
事件驱动系统	DI + SOA + Domain Events
数据密集型应用	DI + SOA + Repository + Unit of Work

---

**请记住：**模式是为了解决问题而存在的。先从问题出发，而不是从模式出发。