企业官网建设流程全解析

前言

很多开发者对架构师的理解，还停留在“画大图、定规范、选中间件”的层面。事实上，架构师手里握着一整套方法论工具，用来应对不同维度的系统复杂性。
领域驱动设计（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”。

五、其他常用工具与思维框架

• 第一性原理：从业务本质出发推导架构，避免盲目照搬行业方案。
• 关注点分离：贯穿所有架构方法的核心原则。
• 康威定律：系统设计会复制组织的沟通结构；可通过调整团队拓扑来影响架构演化。
• 技术债四象限：分类管理不同成因和态度的技术债，指导有序偿还。

六、如何组合这些方法论？

方法论本身不是目的，解决问题才是。以下是一些常见场景下的组合建议：

方法论不是用来束缚创造力的，而是为了让复杂问题可以被“分而治之”地解决。
别成为“方法论收藏家”，要成为“组合大师”。

参考与推荐阅读

• 《实现领域驱动设计》Vaughn Vernon
• 《软件架构设计：大型网站技术架构与业务融合之道》
• 《演进式架构》Neal Ford 等
• 《领域驱动设计》Eric Evans