副标题 / 摘要

设计关注局部方案与细节，架构关注系统整体与演进方向。本文给出清晰的区分框架。

目标读者

  • 需要做系统规划的工程师
  • 参与架构评审的团队
  • 对概念区分有疑问的开发者

背景 / 动机

设计与架构常被混用，导致职责不清或评审混乱。
明确边界有助于协作与决策。

核心概念

  • 设计：局部实现与细节
  • 架构：系统边界与演进路径
  • 抽象层级：架构更高、设计更低

实践指南 / 步骤

  1. 先定义系统边界与约束（架构）
  2. 再落地模块与实现细节（设计）
  3. 用评审分别检查“方向”和“细节”
  4. 保持架构稳定、设计可演进

可运行示例

# 简化“架构 vs 设计”的层级示意
architecture = {"services": ["user", "order"], "db": "postgres"}

design = {"order": {"schema": "orders(id, user_id)"}}

print(architecture)
print(design)

解释与原理

架构关心“系统如何划分与协作”，设计关心“模块怎么实现”。
架构为设计提供约束，设计为架构实现落地。

常见问题与注意事项

  1. 架构是不是设计的一部分？
    可以理解为高层设计。

  2. 架构是否必须固定？
    核心边界应稳定，细节可演进。

  3. 什么时候需要架构师？
    系统规模变大、跨团队协作时。

最佳实践与建议

  • 把架构决策记录成 ADR
  • 设计文档聚焦可实现细节
  • 区分“方向评审”和“实现评审”

小结 / 结论

设计与架构的差别在于范围与抽象层级。
清晰边界能让团队协作更高效。

参考与延伸阅读

  • Software Architecture in Practice
  • Architecture Decision Records

元信息

  • 阅读时长：6~8 分钟
  • 标签：设计、架构
  • SEO 关键词：设计 vs 架构
  • 元描述：解释设计与架构的区别与关系。

行动号召（CTA）

尝试把一个项目的决策分成“架构层”和“设计层”分别记录。