update blog

2025/16. 关于架构设计的几点认知体会/content.md

@@ -51,6 +51,18 @@ graph LR
 
 实际上我挺不推荐用方框图来表达架构的，起码它不应该作为架构表达的重点。因为方框图的信息密度太低、约束性太小，并不适合作为团队内部协作。甚至在我看来，方框图本质是给“外人”看的，给不需要深度参与本项目的人看的。与其花精力用 PPT 做这种图，不如手画来得利索。
 
+那什么才是用来做架构设计的重点呢？
+
+我觉得，好的架构设计应该重点关注**接口约定**、**数据流向**和**边界定义**。说得再直白些，就是要把"谁负责什么"、"怎么交互"、"数据从哪来到哪去"这些问题说清楚。
+
+比如说，与其画个方框图写"用户模块"，不如直接定义清楚：
+
+- 用户注册接口的入参和出参是什么，或者对应 API 长什么样
+- 用户状态有哪几种，状态之间如何流转
+- 用户数据在各个模块间如何传递
+
+这些才是真正需要团队成员协作时用得上的信息。毕竟，大家坐在一起写代码的时候，不会去翻那个精美的方框图，而是会问"这个接口返回什么格式"、"这个字段是必填的吗"、"出错了应该返回什么状态码"等等。
+
 ## 架构设计要紧贴产品，不能本末倒置
 
 架构不是为技术堆料，而是为产品结果服务。不同的产品方向，会导致实现差异很大。所以做架构前，一定要讨论清楚产品方向，最好要有完善的 PRD，即使没有，那也要搞清楚用户故事。