We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
1 parent b91057c commit 68a3e80Copy full SHA for 68a3e80
2025/16. 关于架构设计的几点认知体会/content.md
@@ -51,6 +51,18 @@ graph LR
51
52
实际上我挺不推荐用方框图来表达架构的,起码它不应该作为架构表达的重点。因为方框图的信息密度太低、约束性太小,并不适合作为团队内部协作。甚至在我看来,方框图本质是给“外人”看的,给不需要深度参与本项目的人看的。与其花精力用 PPT 做这种图,不如手画来得利索。
53
54
+那什么才是用来做架构设计的重点呢?
55
+
56
+我觉得,好的架构设计应该重点关注**接口约定**、**数据流向**和**边界定义**。说得再直白些,就是要把"谁负责什么"、"怎么交互"、"数据从哪来到哪去"这些问题说清楚。
57
58
+比如说,与其画个方框图写"用户模块",不如直接定义清楚:
59
60
+- 用户注册接口的入参和出参是什么,或者对应 API 长什么样
61
+- 用户状态有哪几种,状态之间如何流转
62
+- 用户数据在各个模块间如何传递
63
64
+这些才是真正需要团队成员协作时用得上的信息。毕竟,大家坐在一起写代码的时候,不会去翻那个精美的方框图,而是会问"这个接口返回什么格式"、"这个字段是必填的吗"、"出错了应该返回什么状态码"等等。
65
66
## 架构设计要紧贴产品,不能本末倒置
67
68
架构不是为技术堆料,而是为产品结果服务。不同的产品方向,会导致实现差异很大。所以做架构前,一定要讨论清楚产品方向,最好要有完善的 PRD,即使没有,那也要搞清楚用户故事。
0 commit comments