From 9f13f89db8b3857ca33bf5c9cd67515517ffb3ea Mon Sep 17 00:00:00 2001 From: jichangjun Date: Sat, 27 Sep 2025 17:50:07 +0800 Subject: [PATCH] update blog --- .../content.md" | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git "a/2025/16. \345\205\263\344\272\216\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\345\207\240\347\202\271\350\256\244\347\237\245\344\275\223\344\274\232/content.md" "b/2025/16. \345\205\263\344\272\216\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\345\207\240\347\202\271\350\256\244\347\237\245\344\275\223\344\274\232/content.md" index 2a242c0..eb9f3c6 100644 --- "a/2025/16. \345\205\263\344\272\216\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\345\207\240\347\202\271\350\256\244\347\237\245\344\275\223\344\274\232/content.md" +++ "b/2025/16. \345\205\263\344\272\216\346\236\266\346\236\204\350\256\276\350\256\241\347\232\204\345\207\240\347\202\271\350\256\244\347\237\245\344\275\223\344\274\232/content.md" @@ -51,6 +51,18 @@ graph LR 实际上我挺不推荐用方框图来表达架构的，起码它不应该作为架构表达的重点。因为方框图的信息密度太低、约束性太小，并不适合作为团队内部协作。甚至在我看来，方框图本质是给“外人”看的，给不需要深度参与本项目的人看的。与其花精力用 PPT 做这种图，不如手画来得利索。 +那什么才是用来做架构设计的重点呢？ + +我觉得，好的架构设计应该重点关注**接口约定**、**数据流向**和**边界定义**。说得再直白些，就是要把"谁负责什么"、"怎么交互"、"数据从哪来到哪去"这些问题说清楚。 + +比如说，与其画个方框图写"用户模块"，不如直接定义清楚： + +- 用户注册接口的入参和出参是什么，或者对应 API 长什么样 +- 用户状态有哪几种，状态之间如何流转 +- 用户数据在各个模块间如何传递 + +这些才是真正需要团队成员协作时用得上的信息。毕竟，大家坐在一起写代码的时候，不会去翻那个精美的方框图，而是会问"这个接口返回什么格式"、"这个字段是必填的吗"、"出错了应该返回什么状态码"等等。 + ## 架构设计要紧贴产品，不能本末倒置 架构不是为技术堆料，而是为产品结果服务。不同的产品方向，会导致实现差异很大。所以做架构前，一定要讨论清楚产品方向，最好要有完善的 PRD，即使没有，那也要搞清楚用户故事。