第 3 章 贯穿案例的引入
副题：一个人、一句话、一台服务器的预算——地图从此有了原点
第 1 章你拿到了地图，第 2 章你看到了地图为什么一直在变大。但地图上还缺一样东西：一个原点。这一章，我们把一个具体的产品放上地图——一个最小的社区交易产品。从此，每一章的业务场景都锚在它的成长上，每一项技术，都能问出"是什么问题逼出了它"。
本章要建立的认知
- 全书只有一个案例——一个最小的社区交易产品。第 4 章到第 27 章的业务场景都锚在同一条时间线上，不换案例。
- 六对象、五阶段、一张架构图是全书的三个锚点：对象回答"业务由什么构成"，阶段回答"业务走到了哪里"，架构图回答"技术住在哪里"。读任何一章，先问"业务现在走到哪个阶段了"。
- "业务逼出技术"在本章第一次显形——对象是被业务动词逼出来的，技术是被阶段问题逼出来的。同一个逻辑，两个尺度。
3.1 本章要建立的认知
深夜，你翻开一个崭新的产品笔记本，在第一页写下一句话：
做一个社区交易产品：有人发内容、评论，也能上架商品、下单付款。
写完环顾四周：没有团队，没有表，没有服务器——手里的预算，只够租一台服务器。这是产品的第 0 天。本书剩下的一切，都从这句话开始。
第 1 章给了你地图，第 2 章解释了地图为什么一直在变大。本章做的事，是在地图上插一面旗：一个具体的产品，一条具体的路线。旗子插下去，后面每一章才有坐标可回。
前两章里，这个产品还是"别人的故事"。从现在起，它是你的了——第 2 章那五个阶段，将在你手上逐一发生；每个决策、每次返工、每场事故，都由你亲历。
为什么只用一个案例？因为这本书教的不是技术的广度，而是决策的深度。每章换一个案例，每个案例都只能看一眼，你记住的只会是名词；盯住一个产品从头走到尾，你才能看到一个决策怎么诞生、怎么付出代价、怎么演进。
本章不讲任何技术，只做一件事：把案例立起来。立案例就是立三个锚点——六对象、五阶段、一张架构图。读完本章，你手里就有了读后面任何一章的三个问题：业务现在走到哪个阶段了？问题出在哪个对象上？这项技术住在架构的哪一格？
3.2 产品的第 0 天：一句话需求与一份盘点
第 0 天从盘点开始。
你手里只有一句话，把它拆开：一句话里有五个动作——发内容、评论、上架商品、下单、付款。还有一个没说出来但少不了的：有人发，就得有人看——浏览。动作背后是最小功能集：
- 社区一侧：注册登录、发布内容、评论、浏览内容流；
- 交易一侧：上架商品、下单、付款。
这个产品做给谁？做给想在同一个圈子里分享、讨论、顺手互通有无的人。对他们来说，社区是日常，交易是顺带。这个定位会影响你很快要做的一个决定：这些功能，先做哪些、后做哪些？答案不是全做——一台服务器的预算、一个人的开发周期，撑不起全部功能并行。先社区，后交易：先做内容与评论，让人留下来；交易后置，放到后面的阶段再开启。为什么后置是对的，第 4 章讲 MVP 时正式展开——那一章会把这句话翻译成一份可开发的需求清单。
你可能已经开始怀疑：这么小的产品——一个人、一台服务器、五个动作——值得用二十五章去讲吗？恰恰因为小：小到能把"业务问题怎么逼出技术"的完整过程摊开给你看——真实系统都太大了，只能讲它的结果，讲不了它做决定的现场。而且你要学的也不是这个案例本身：六对象会过时，五阶段会走完，但"业务到了什么阶段、出了什么问题、逼出了什么技术"这套问法，换成你维护的任何系统都成立。
这句话不会停在笔记本里。第 4 章把它翻译成需求清单，第 5 章用它选技术栈，第 6 章把它变成六张表，第 7 章把动作变成接口。这四章的顺序不可交换：翻译清楚了才能选型，选型定了才能建表，表定了，接口的形状就定了一半。第二部分这四章，合起来就是一句话需求的旅程：从说出口，到变成图纸。
3.3 六对象：业务世界的骨架
再看这个产品的业务世界由什么构成。
六个对象：用户、内容、评论、商品、订单、支付。第 1 章已经报过名单，这一节回答另一个问题：为什么恰好是这六个，不是五个，也不是八个？
答案藏在那句话里。逐动词问一遍：
- "有人发内容"——得先有"人"，这是用户；还得有被发的东西，这是内容。
- "评论"——评论挂在内容上，需要第三个对象：评论。
- "上架商品"——被上架的是商品，上架的人还是用户。
- "下单付款"——下单产生订单，付款产生支付。
六个对象，没有一个是谁提前设计出来的，全是被业务动词逼出来的。这是"业务逼出"在全书的第一次显形——对象层面的：业务动作在先，结构跟着长出来。往后你会看到，技术也是这样出生的。
那拆错了会怎样？假设你不想弄这么多对象，直接把"商品"做成一种特殊的"内容"——帖子标个价格就算上架。社区阶段这样很省：一张表、一套接口、一个列表页。可一旦开启交易，你会为这份省付出代价：内容删除和订单保留开始打架——帖子删了，订单引用的商品是什么？发帖人和卖家的责任混在一起；"草稿/发布/删除"和"在售/下架"两套生命周期缠在同一组状态里。到那时再把商品从内容里拆出来，代价比一开始多建一张表高得多。对象怎么拆，是系统的第一个设计决定，它决定系统能长到多大。第 6 章会正式做这个拆分：把六对象变成六张表。
六个对象的关系，清楚地分成两个世界。
社区世界：用户发布内容，其他用户评论内容。内容与评论撑起社区的日常。交易世界：用户上架商品，其他用户对着商品下单、付款；商品生出订单，订单触发支付。用户是连接两个世界唯一的桥——发内容的人和下单的人，是同一批人。
这个结构决定了很多事：信息架构为什么是"社区为主、交易为辅"（第 4 章会回到这一点）；交易功能为什么可以干净地后置——因为社区世界自己能站住；交易开启之后为什么必须格外小心——订单的另一头，是每天发帖评论的同一批人，信任碎了，社区也就碎了。
每个对象再说一句它在全书的"命运"，只预告，不展开：
- 用户：身份是一切的前提——系统怎么记住"你是谁"，第 13 章讲。
- 内容：读热点的源头。阶段 2 的性能危机从"首页打不开"开始，首页就是内容列表——第 16 章。
- 评论：楼中楼会逼出一个建模难题，第 6 章展开。
- 商品：库存字段是超卖的源头，第 17 章。
- 订单：全书最复杂的对象，一个六状态的状态机，第 17 章。
- 支付：把钱接进系统的对象（第 17 章），也是将来第一个被拆出去的服务（第 26 章）。
读到这里你可能会问：购物车呢？优惠券呢？关注、私信呢？
都不在。六对象是支撑全书主线的最小集，不是业务概念大全。新对象进入这个集合只有一个入口：被业务逼出来。第 27 章会有一个叫"二手拍卖"的新需求上门，那时全书会第一次演示新对象怎么进场。在那之前，六对象就是六对象。
这也是读这本书的一条原则：每章讲一项新技术，先问它是从哪个对象、哪个阶段长出来的——而不是问案例"用没用到"这项技术。
3.4 五阶段：全书的时间线
对象回答了"业务由什么构成"，阶段回答"业务走到了哪里"。
第 2 章已经用过五阶段——那次是当证据用的：证明演进循环存在，给你看每个阶段的转换与代价。本章换个角度看同一条故事线：把它当成这个产品即将走完的路线。第 2 章看它的形状，本章给它坐标——每一站在哪、什么问题、对应哪些章。
| 阶段 | 业务进展 | 业务问题 | 逼出的技术 | 章节 |
|---|---|---|---|---|
| 1 想法期 | 一个人验证想法，日活三位数以内 | 快速上线、人手少 | 单体架构、PostgreSQL、基础前后端 | 4-15 |
| 2 用户增长 | 注册破 10 万，日活 ~1 万 | 慢、卡、扛不住 | Redis 缓存、CDN、索引优化 | 16 |
| 3 交易增长 | 开启交易，日订单千级 | 下单付款不能出错 | 事务、幂等、支付、异步/消息 | 17-19 |
| 4 团队增长 | 1 人 → 8 人 | 交付慢、故障多 | CI/CD、可观测性、高可用 | 20-25 |
| 5 规模增长 | DAU 10 万级、日订单 5 万、团队 30 人 | 系统复杂、协作难 | 服务拆分、事件驱动 | 26-27 |
每一站，一口气说完：
**阶段 1 是全书最长的一站——12 章。**你会跟着走完从需求到 MVP 上线的全程：翻译需求（第 4 章）、选技术栈（第 5 章）、建表（第 6 章）、定接口（第 7 章），然后进运行时走一整圈——浏览器（8-9 章）、网络（10-11 章）、服务端（12-13 章）、数据层（14 章），直到全链路走通、MVP 上线（第 15 章）。这一站选的技术刻意简单——单体、PostgreSQL、基础前后端——因为这一站的业务问题是"快速上线"，不是"扛得住多少"。
**阶段 2，首页开始打不开。**用户涨起来了，内容涨起来了，每一次刷新都是一次数据库查询，原方案扛不住了。CDN 和缓存其实早已露过面——第 11 章初识 CDN，第 14 章打过缓存的底——第 16 章回到这场危机，把它们正式请进场。
**阶段 3，开始收钱。**问题的性质变了：慢一点可以忍，错一分都不行。重复下单、回调丢失、库存超卖，每一种事故都逼出一套机制——状态机、事务、幂等、对账（17-19 章）。收钱还带来一件副产品：商业化会引来攻击者，安全问题从这一站起正式入局（第 19 章）。
**阶段 4，团队从 1 个人长到 8 个人。**问题从机器转向人：合并冲突、发布互踩、故障靠"谁在电脑前谁处理"。CI/CD、可观测性、高可用——这些技术管的是协作和信任，不只是代码（20-25 章）。
**阶段 5，单体本身成了瓶颈。**30 个人改一个仓库，发布互相踩，一次故障全站遭殃。服务拆分和事件驱动提上日程——第 26 章会收回第 2 章埋在那里的伏笔。
怎么知道走到了下一站？信号从来不是日历，是业务信号：首页开始变慢，是阶段 2 的信号；第一次出现重复扣款的投诉，是阶段 3 的信号；发布开始需要互相打招呼，是阶段 4 的信号。第 5 章定下阶段 1 的技术栈时，会把演进条件一并写进决策记录：缓存，等首页变慢再说；服务拆分，等单体的痛点看得见再说。"业务没到就不上"和"业务到了就别躲"，是同一句话的两半。
这五个阶段不只是案例的故事。如果你现在手里维护着一个系统，可以拿这张表对一对：它是慢（阶段 2）？是开始收钱（阶段 3）？还是团队开始变大（阶段 4）？系统当前的业务问题，大致能告诉你它在哪个阶段——以及这个阶段值得评估什么技术。从第 4 章起，每进一章先问一句：案例现在走到哪一站了？这一章的技术是被什么问题逼出来的？这两个问题，就是全书的阅读节奏。
3.5 Web 系统总架构：案例住在哪里
业务侧讲完，切到技术侧。这个产品作为一个 Web 系统，长什么样？
图 3-3 是全书的第二张一级图（第一张是第 1 章的全书技术地图）。它把系统画成四个格子：
- 浏览器：用户直接看到和摸到的地方，页面在这里渲染，交互在这里发生。
- 网络：请求走的路——DNS 问路、CDN 抄近道、HTTP 规定怎么说话。
- 服务端：业务规则住的地方，接收请求、执行逻辑、返回结果。现在里面只画一个方块——单体应用，所有功能在一个进程里。
- 数据层：数据住的地方。数据库已经在位；缓存的位置先空着——阶段 2 首页扛不住时，Redis 会坐进来。服务端入口还缺一个负载均衡（LB）——等阶段 4 有了多台服务器才需要它。
图里这两处"阶段 2/阶段 4 引入"的虚线座位，阶段 1 都不存在。先把座位画在图上，等你后面遇到它们时会发现：它们早在地图上等着了。
对照第 1 章你会发现：图 3-3 的四个格子，正是技术线的四站——浏览器 → 网络 → 服务端 → 数据层。第 1 章的技术线是远远的一条线，从这里开始，它变成可以住进去的格子。
现在不需要看懂每一格。第 8-15 章会逐格放大：8-9 章放大浏览器，10-11 章放大网络，12-13 章放大服务端，14 章放大数据层，第 15 章把四格串成一次完整的请求旅程。图 3-3 就是第三部分的索引——读哪一章，都知道它在放大哪一格。
再把六对象放回这张图。数据住在数据层：用户、内容、评论、商品、订单、支付，六张表，第 6 章建。业务规则住在服务端：谁能发帖、库存怎么扣、订单状态怎么流转——第 7 章的接口、第 12 章的分层，组织的就是这些规则。界面住在浏览器：用户看到的，是内容、商品、订单在屏幕上的投影。
同一批对象，图 3-1 里是业务关系，图 3-3 里是技术落位——同一个系统，两张视图。这个读图习惯后面还会用到：第 23 章给"组成"和"部署"两张视图，第 26 章会展示这张架构图怎么长大。
这张图在全书的用法只有一条：不记组件细节，记每项技术住在哪一格。Redis 住数据层，CDN 住网络层；CI/CD 这类工程技术不住在图上——它是工程线的事，不在运行时旅程里。后面每出现一项新技术，第一反应是把它放回图 3-3：先定位，再理解。
3.6 与全书地图的关系
回头看第 1 章的图 1-1：三条线交汇在"社区交易产品"这个节点上。从本章起，这个节点有了内容——六对象是它的业务线实体，五阶段是它的生命周期坐标，图 3-3 是它的运行时切面。地图不再是一张抽象的图，它有了一个原点。
三条线从此各有落点：业务线走的是五阶段；技术线从图 3-3 的四格之间穿过——一次请求的旅程；工程线陪的是团队从 1 个人长到 8 个人、再长到 30 个人的过程。
最后兑现一个承诺。第 1 章声明过全书的原则——业务逼出技术。这个原则怎么展开？看三个例子——运行时两个，工程侧一个。
缓存不是因为时髦才引入的，它是被"内容被反复地读"逼出来的：首页的内容列表每天被几万人刷，数据库扛不住了，Redis 才进场（阶段 2，第 16 章）。事务则不是教科书的要求，它是被"订单和支付必须同生共死"逼出来的：库存扣了、钱没付成，或者钱付了、订单没更新——两种裂缝都不能接受（阶段 3，第 17 章）。再看工程侧：CI/CD 更不是大公司的风尚，它是被"发布不再是一个人做"逼出来的——一个人发布，口头核一遍就够；八个人发布，手动部署开始互相踩，自动化就成了唯一的协作方式（阶段 4，第 22 章）。
一个被逼自单个对象的读热点，一个被逼自两个对象之间的关系，一个被逼自团队的规模。这本书里几乎每一项技术，都这样从业务里长出来——第 1 章的断言，在这里有了第一批证据；第 4 章到第 27 章，会继续补证。
3.7 小结：三个锚点
本章为全书立了三个锚点：
- 六对象——业务由什么构成。两个世界，一座桥，最小集。
- 五阶段——业务走到了哪里。每一站的业务问题，逼出每一站的技术。
- 一张架构图——技术住在哪里。四个格子，第 8-15 章逐格放大。
从此读任何一章，先问三个问题：业务走到哪个阶段了？问题出在哪个对象上？技术住在架构哪一格？
不过，笔记本里那句话还不是需求——它只是个起点。做什么、不做什么、多快算快，全都还含糊着。下一章，业务线正式启动：把"做一个社区交易产品"翻译成一份能开发、能验收、能用来选型的清单。第一次翻译就出了事故，事故的代价，叫返工。