文章目录前言一、架构风格与系统划分方法1. 领域驱动设计 (DDD)2. 分层架构 (Layered Architecture)3. 六边形架构 (Hexagonal Architecture / Ports Adapters)4. 整洁架构 (Clean Architecture)5. 事件驱动架构 (EDA)6. 微服务架构 (Microservices)7. CQRS (命令查询职责分离)8. 事件溯源 (Event Sourcing)二、需求分析与领域建模方法9. 用例驱动 (Use Case Driven)10. 用户故事映射 (User Story Mapping)11. 事件风暴 (Event Storming)12. 业务能力建模 (Business Capability Modeling)13. C4 模型 (Context, Container, Component, Code)三、质量属性与架构评估14. ATAM (架构权衡分析法)15. 质量属性场景四、架构决策与治理16. ADR (架构决策记录)17. RFC 流程 (Request for Comments)18. 架构适配度函数 (Fitness Functions)五、其他常用工具与思维框架六、如何组合这些方法论参考与推荐阅读前言很多开发者对架构师的理解还停留在“画大图、定规范、选中间件”的层面。事实上架构师手里握着一整套方法论工具用来应对不同维度的系统复杂性。领域驱动设计DDD只是其中最常讨论的一把利器但要真正驾驭大型系统你还得知道它旁边放着的其他“家伙”。这篇文章我把架构师常用的方法论整理成一张全景地图希望能帮你建立完整的认知。一、架构风格与系统划分方法1. 领域驱动设计 (DDD)解决什么问题复杂业务领域的建模让软件模型直接反映业务概念。关键概念限界上下文、上下文映射、实体、值对象、聚合、领域事件等。核心价值战略设计划定边界战术设计指导实现通用语言统一认知。一句话总结DDD 是处理业务复杂度的利器不等于微服务也不等于代码模板。2. 分层架构 (Layered Architecture)最常见的“表现层 - 应用层 - 领域层 - 基础设施层”结构。强调单向依赖上层调用下层层次清晰。适合业务逻辑相对简单的系统但在复杂业务下容易出现“胖 Service 层”演变成大泥球。3. 六边形架构 (Hexagonal Architecture / Ports Adapters)由 Alistair Cockburn 提出。核心思想业务逻辑处于中心所有外部依赖数据库、UI、消息队列都是“外部世界”通过端口接口和适配器接入。与 DDD 高度互补让领域层纯粹且完全可测试。4. 整洁架构 (Clean Architecture)由 Robert C. Martin 提出核心是依赖规则依赖只能由外向内内层绝不依赖外层。分层方式实体企业级业务规则→ 用例应用级规则→ 接口适配器 → 框架与驱动。与六边形架构理念相通更强调依赖反转原则DIP。5. 事件驱动架构 (EDA)通过事件在组件/服务间异步通信实现松耦合。关键要素事件生产者、消费者、事件通道、事件存储。常与微服务、CQRS 配合使用适合对最终一致性可接受的业务场景。6. 微服务架构 (Microservices)将系统按业务能力拆分为一组小型、自治的服务。常与 DDD 的限界上下文对齐一个限界上下文通常对应一个微服务。需要配套服务发现、配置中心、可观测性、容错等基础设施不适合盲目拆分。7. CQRS (命令查询职责分离)将读操作Query和写操作Command的模型彻底分离。写侧使用严谨的领域模型保证一致性读侧可按需建立宽表或 NoSQL追求高性能。常与事件溯源联用但不是绑定关系。8. 事件溯源 (Event Sourcing)不保存当前状态而是保存所有状态变更事件通过重放事件重建当前状态。天然适合审计、调试、状态回溯等场景。复杂度较高通常需要快照优化重放性能。二、需求分析与领域建模方法9. 用例驱动 (Use Case Driven)以用户目标和交互流程驱动系统功能分析。适合需求初期明确系统边界和对外承诺。可与用户故事结合避免过早陷入数据建模。10. 用户故事映射 (User Story Mapping)由 Jeff Patton 提出将用户故事按“用户旅程”排列成二维地图。帮助团队建立产品全貌视图制定发布切片和迭代计划。11. 事件风暴 (Event Storming)DDD 社区带来的快速建模工作坊方法。通过贴纸引导领域专家和开发团队共同识别领域事件、命令、聚合、外部系统等。实践经验数小时内即可让复杂业务流程透明化是我最推荐的 DDD 落地起步工具。12. 业务能力建模 (Business Capability Modeling)从“组织能做什么”的角度抽象出稳定的业务功能模块不关心具体实现。是微服务拆分的常见起点比按技术层拆分更稳定。13. C4 模型 (Context, Container, Component, Code)专为软件架构设计的轻量级可视化方法。四个层次系统上下文图 → 容器图 → 组件图 → 代码图。不同角色可聚焦不同层次比 UML 更易上手和沟通。三、质量属性与架构评估14. ATAM (架构权衡分析法)SEI 提出的系统化评估方法通过质量属性场景暴露架构中的风险点、权衡点、敏感点。使用时机重大技术选型、架构评审、接手遗留系统。15. 质量属性场景将“高性能”“高可用”等模糊需求转化为可验证的场景卡片。标准六元组格式[刺激源] [刺激] [环境] [制品] [响应] [响应度量]。示例1000 并发用户在正常网络下查询订单列表系统在 2 秒内返回结果。四、架构决策与治理16. ADR (架构决策记录)轻量级文档记录架构决策的背景、决策内容、后果及备选方案。让架构知识不丢失新成员能快速理解“当初为什么这么做”。常用字段标题、状态、背景、决策、后果。17. RFC 流程 (Request for Comments)在做出重大架构变更前先编写提案文档征集团队意见、达成共识后再实施。降低孤岛决策风险特别适合多团队协作的项目。18. 架构适配度函数 (Fitness Functions)源自《构建演进式架构》用自动化测试持续验证架构特征防止架构随迭代退化。例如用 ArchUnit 检查“domain 层不能依赖 infrastructure 层”或用性能测试验证“P99 延迟 200ms”。五、其他常用工具与思维框架第一性原理从业务本质出发推导架构避免盲目照搬行业方案。关注点分离贯穿所有架构方法的核心原则。康威定律系统设计会复制组织的沟通结构可通过调整团队拓扑来影响架构演化。技术债四象限分类管理不同成因和态度的技术债指导有序偿还。六、如何组合这些方法论方法论本身不是目的解决问题才是。以下是一些常见场景下的组合建议场景推荐方法论组合复杂核心业务系统电商、金融DDD 六边形架构 CQRS ADR快速交付的初创项目分层架构 用户故事映射 轻量级 ADR臃肿单体的改造事件风暴梳理限界上下文 微服务拆分 RFC高并发查询与事务混合CQRS 事件驱动 异步读模型遗留系统架构治理ATAM 评估 适配度函数 重构决策记录方法论不是用来束缚创造力的而是为了让复杂问题可以被“分而治之”地解决。别成为“方法论收藏家”要成为“组合大师”。参考与推荐阅读《实现领域驱动设计》Vaughn Vernon《软件架构设计大型网站技术架构与业务融合之道》《演进式架构》Neal Ford 等《领域驱动设计》Eric Evans