新一代架构师（初级篇）：从业务分析到API设计

先别急着写接口：业务没想清楚，API 只是空壳

很多初级开发者拿到需求，第一反应是“这个功能要几个接口”“参数怎么传”。结果做出来的接口要么跟业务对不上，要么过两天就要改。问题往往不在编码，而在动手之前缺少对业务领域的拆解。这门课的主题就是：怎么从一段业务描述出发，经过领域知识分析和设计思考，落到一份可执行的 API 设计上。它不是讲语法或框架，而是补上“从需求到接口”之间那段最容易被跳过的思考过程。

这门课解决什么问题，适合什么基础

它解决的核心问题是：你懂写代码，但不一定懂“业务建模”。比如买主知识、领域边界、业务规则这些概念，如果不先梳理清楚，API 的命名、职责、粒度都会很随意。课程用五子棋作为业务分析示例，因为规则明确、边界清晰，适合用来练习“把业务语言翻译成技术语言”的方法。之后又回到企业框架的 API 设计，演示如何把设计思考的方法套用到真实场景。

适合的基础：能独立完成增删改查、熟悉常见 Web 框架，但没系统做过架构设计，或者做过接口却总被测试/业务方挑毛病的人。不需要你懂 DDD 或微服务，课程会从更基础的“领域知识”讲起。如果你已经能熟练设计 RESTful 接口，但想搞清楚“为什么这样设计”的底层逻辑，这门课也值得看。

建议先看哪几块，学完能独立做什么

建议把注意力集中在两块：一是业务（领域）知识分析，二是设计思考演练。前者教你如何从一段业务描述中提取关键概念、规则和边界；后者给你一个可操作的思考框架，避免拍脑袋定接口。五子棋那节是前者的具体演示，可以对照着看，理解“抽象”是怎么发生的。最后的企业 API 设计是综合应用，看完能知道前面那些分析怎么落到接口的路径、参数和响应结构上。

学完这门课，你应该能独立完成一个小型业务场景的建模：比如自己选一个熟悉的小业务（图书借阅、点餐、库存管理），先画出业务对象和关键流程，再依据这些设计出至少一组合理的 API，并且能解释每个接口为什么存在、为什么这样划分。

资料怎么配合练习

看视频时不要只“听”案例，要跟着动手。每学完一节，就暂停视频，把五子棋的案例自己重新推演一遍：先写业务描述，再列领域词汇，最后设计接口。然后换一个自己熟悉的业务，用同样步骤走一遍。资料包里如果提供了示例文档或代码，不要直接打开看答案，先自己做完再对照，看差距在哪里。这样重复两三次，你就能把“业务分析到 API 设计”的思考过程内化成自己的习惯，而不是记住某个具体案例的结论。