设计模式与架构设计
大约 4 分钟约 1239 字
设计模式与架构设计
专题简介
本专题聚焦“设计原则、GoF 设计模式、架构模式、函数式思维与事件驱动建模”，目标不是只记住模式名称，而是帮助你在真实项目里判断：什么时候该抽象、怎么抽象、抽象过度会带来什么成本。当前这一专题已经覆盖面向对象、DDD、SOLID、23 种经典模式以及一批常见架构模式，已经可以形成相对完整的阅读闭环。
适合谁看
- 想把“能写功能”提升到“能设计结构”的开发者
- 正在做中后台、企业系统、微服务或复杂桌面客户端的人
- 需要准备架构面试、内部分享或团队规范沉淀的人
- 已经知道模式名，但还不会判断适用边界的人
推荐阅读路径
路线一：从概念到模式
路线二：从真实项目问题切入
- 代码中
if/else特别多、扩展困难：- ✨ 策略模式
- 对象创建逻辑复杂、构造参数过多：
- 想做解耦通知、事件广播：
- ✨ 观察者模式
- 老系统改造、逐步迁移：
- 复杂业务流程跨服务：
- ✨ Saga 模式
- 仓储和事务边界不清：
专题结构总览
一、基础思想与设计原则
二、GoF 设计模式导览
三、创建型模式
四、结构型模式
五、行为型模式
六、架构模式与工程实践
- ✨ Repository + UnitOfWork
- Specification 模式
- Pipeline 模式
- ✨ Saga 模式
- Memoization 模式
- Strangler Fig 绞杀者模式
- 六边形架构（端口与适配器）
- 缓存设计模式
- 分布系统设计模式
- 前端设计模式
- 错误处理模式
- 数据访问模式
- 并发模式
如何阅读才最有效
- 不要按“模式名字”背诵，而是按“解决什么问题”来读。
- 每读一篇，都问自己三件事：
- 它解决了什么具体痛点？
- 它会引入什么额外复杂度？
- 我的项目里有没有更简单的替代方案？
- 对于每个模式，尽量形成“适用场景 / 不适用场景 / 与相邻模式区别”的笔记。
项目落地建议
- 小项目优先追求简单直接，不要为了“用模式而用模式”。
- 中大型项目中，优先把设计模式作为消除重复、隔离变化、降低耦合的工具。
- 架构模式要结合日志、测试、配置、部署和回滚一起理解，不能只停留在代码层。
- 团队协作里，模式的价值常常体现在：新人更容易理解、变更范围更可控、测试更容易落地。
常见误区
- 看到模式就兴奋，最后把简单问题做复杂。
- 只理解 UML 或类图，不理解真实业务触发条件。
- 把设计模式当银弹，不看项目规模和团队能力。
- 只会说模式定义，回答不了“为什么这里要用、那里不要用”。
学完后要能做到
- 能从代码坏味道中判断：这里更像缺少策略、观察者，还是只是简单函数抽取。
- 能解释常见模式之间的区别，比如工厂 vs 建造者、装饰器 vs 代理、状态 vs 策略。
- 能把一两个模式真正迁移到自己的项目，而不是停留在概念层。
- 能从“项目演进和维护成本”的视角看待设计，而不是只看一时写代码快不快。
建议后续补读
如果你学完本专题，建议再顺着这些方向继续：