#架构风格

系统变慢了。你加了几台服务器、换了更快的数据库、上线了缓存，但效果还是不明显。问题到底在哪？

很多团队在这个阶段会继续在细节上打转——换个 ORM、换个连接池、换个消息队列。但真正的问题，往往在更高层：你的架构风格，正在成为系统扩展的瓶颈。

架构风格不是「用什么框架」那么简单。它决定了你如何划分系统边界、如何管理依赖关系、如何应对需求变化。当业务简单时，架构风格的影响不明显；当业务复杂到一定程度，架构风格的优劣会直接决定你是「快速迭代」还是「每次改一行代码都要改一周」。

本模块聚焦后端架构的核心风格，从分层架构到六边形架构，从事件驱动到 CQRS，帮你建立完整的架构视野。

#模块结构

本模块按主题分为以下子模块：

#核心演进路径

架构风格不是「最新的最好」，而是「最合适的最好」。理解各种风格的演进逻辑，能帮助你做出更合理的技术选型：

flowchart TD
    A["单体分层\n最朴素的组织方式"] --> B["六边形架构\n引入端口与适配器"]
    A --> C["洋葱架构\n强化依赖方向"]
    A --> D["整洁架构\n统一内层依赖原则"]
    B --> C
    C --> D
    E["传统 CRUD"] --> F["CQRS\n读写分离"]
    F --> G["事件溯源\n用事件代替状态"]
    F --> H["EDA\n事件驱动架构"]
    I["简单 API"] --> J["REST\n资源导向"]
    J --> K["GraphQL\n按需获取"]

#与设计模式的区别

很多人容易把架构风格和设计模式混为一谈，这里做一个澄清：

设计模式是战术层面的工具，架构风格是战略层面的决策。一个好的架构应该能让设计模式发挥最佳效果，而不是限制它们的使用。

#为什么需要了解架构风格

架构风格是技术选型的起点。不同业务场景需要不同的架构，没有银弹，但有更合适的选择。

小团队（<= 5人）、简单业务（CRUD + 少量并发）：

• 推荐分层架构
• 不要过度设计，避免把简单问题复杂化
• 随着团队成长再考虑迁移

中等规模团队（5~20人）、中等复杂度业务：

• 考虑六边形架构或整洁架构
• 核心是建立清晰的边界和依赖规则
• 不要盲目引入 CQRS 或事件溯源

大规模团队（20人以上）、复杂业务：

• 根据具体场景选择 CQRS + EDA
• 需要配套的运维、监控、事务管理能力
• 架构风格的变更成本很高，前期决策要谨慎

#本章文章导读

如果你时间有限，可以按以下优先级阅读：

1. 必读：分层架构（Layered）—— 这是理解其他架构的基础
2. 推荐：六边形架构（Hexagonal）—— 理解依赖倒置的核心思想
3. 推荐：整洁架构（Clean）—— 与六边形一脉相承，理解内层不依赖外层的原则
4. 选读：CQRS + 事件溯源—— 如果你有读写分离或审计追踪的需求
5. 选读：EDA 事件驱动 —— 如果你在做微服务解耦或数据集成
6. 了解：微内核、管道-过滤器、MVC/MVVM、REST、GraphQL —— 根据具体场景查阅

准备好了吗？让我们从最经典的分层架构开始。