Redis架构演进全解析：单机、主从、哨兵与Cluster实战
2026/10/22 15:08:51
我为什么要写一个 DDD 系列：一份写给"不敢重构"的人的路线图
这是「DDD 实战系列」的第 0 篇，也是整条路线的入口。它不教你任何建模技巧——那是后面 10 篇的事。这篇只做一件事：帮你判断自己该从哪篇下嘴，以及这条路最终要把你带去哪里。
一、先回答一个问题
先别急着翻目录，回答我一个问题：
如果现在有人说"把那个OrderService重构成 DDD"，你脑子里第一个冒出来的，是"充血模型""四层架构"这些名词，还是"我的订单规则到底散落在哪几处、改起来要动几个文件"？
如果你的第一反应是前者，那这个系列就是为你写的。
我翻过不少 DDD 的中文资料，一个普遍的毛病是：上来就堆名词——实体、值对象、聚合、限界上下文、领域事件、六边形架构……名词都认识，合上书还是不知道怎么对自己那个几千行的 Service 下手。DDD 的真正定义其实很朴素：
让软件的代码结构，与业务的语言、规则、边界保持同构。
它不是分层架构，不是充血模型的语法糖，更不是一套"标准包名"。它是解决一个具体问题的工具：业务一大，规则散落，变更失控，系统腐化。这个系列想做的，是把"名词"还原成"判断"——什么时候该用、什么时候千万别用、用了要放弃什么。
所以这篇导读，写给三种人，尤其第一种：
- 不敢重构的后端：守着一个几百行甚至几千行的
OrderService，知道该改，但一动就怕崩； - 听过没落地的中级：蓝皮书翻过、名词都懂，真到建模判断时还是靠拍脑袋；
- 想系统学的人：零基础入门，或者带团队定架构与选型的技术 Leader。
二、这条路线怎么走：11 篇地图
整个系列一共11 篇，从"为什么需要 DDD"一路讲到"三大实战案例与落地路线图"。11 篇不是随意堆的，它沿着三条主线铺开，对应 DDD 只回答的三个问题：
| 主线 | 篇目 | 回答的问题 |
|---|---|---|
| 战略设计 | 02、03 | 系统怎么切？边界在哪？块之间怎么协作？ |
| 战术设计 | 04、05 | 边界内部的类怎么建模？规则写在谁身上？ |
| 架构与落地 | 06~10 | 模型怎么落到代码结构？真实业务怎么用？渐进式怎么走？ |
把这 11 篇连成一张图，走向是这样的（颜色只用来区分三条主线，不表示好坏）：
flowchart TD A["01 · 为什么需要 DDD<br/>贫血痛点与三条原则"] --> B["02 · 战略设计：子域与通用语言"] B --> C["03 · 战略设计：限界上下文与映射"] C --> D["04 · 战术设计：实体/值对象/聚合"] D --> E["05 · 战术设计：事件/服务/仓储"] E --> F["06 · 架构模式：四层与六边形"] F --> G["07 · 实战一：电商订单"] G --> H["08 · 实战二：银行转账"] H --> I["09 · 实战三：单体渐进拆分"] I --> J["10 · 落地路线图与误区"] style A fill:#FAFAFA,stroke:#A1A1AA style B fill:#FAFAFA,stroke:#A1A1AA style C fill:#FAFAFA,stroke:#A1A1AA style D fill:#FAFAFA,stroke:#0F6E56 style E fill:#FAFAFA,stroke:#0F6E56 style F fill:#FAFAFA,stroke:#A32D2D style G fill:#FAFAFA,stroke:#A32D2D style H fill:#FAFAFA,stroke:#A32D2D style I fill:#FAFAFA,stroke:#A32D2D style J fill:#FAFAFA,stroke:#A32D2D记住这个结构：战略是"切"（02、03），战术是"填"（04、05），落地是"跑"（06 起）。切错了，后面填得再漂亮也是白费。所以第 10 篇的误区里，第一条就是"绝大多数重构死在了上来就看代码"——你应该先划边界，再碰代码。
三、三类读者，分别怎么读
同样 11 篇，不同人读法完全不同。我给三类读者各画了一条路径，核心是：先定位你是谁，再决定从哪篇下嘴，读到"够用"就合上，不必硬啃全部。
人群 A · 不敢重构的后端（先看痛点，再动手）
你的痛点是"想动不敢动"。别一上来读战略，那会让你更不敢动。先读01，用那个"全局搜索一条规则"的实验确认自己的系统确实在流血；然后直奔04 / 05战术设计，学怎么把一条规则收进模型；最后拿07 电商订单照着改一笔订单练手。你的终点是：能把一条核心规则收敛到唯一一处。到了这步，你已经比大多数"懂 DDD 名词"的人能打了。
人群 B · 听过没落地的中级（战略优先，案例验证）
你缺的不是概念，是"判断"。跳过 01，直接读02 / 03战略设计——先划边界、建通用语言，再碰代码；接着拿07 / 08 / 09三个真实案例照练，看别人怎么在真实业务里切上下文、做最终一致；最后用10的误区清单和自己的坑对账。你的终点是：能对着现有系统画出边界、说清一处建模的取舍。
人群 C · 想系统学 / 技术 Leader（顺序打底，按需加速）
零基础就01 → 06顺序打底，从"为什么"一路走到"架构模式"；带团队定架构的 Leader，则重点读02、03、09、10（战略与组织落地），战术部分快速过。三类人最终都要走到10的六步路线图与体检清单。你的终点是：能讲清"为什么这么切"，并带着团队照路线图走。
💡我的设计笔记 · 一
我为什么做这个系列，以及我放弃了什么。
DDD 的中文资料已经很饱和，蓝皮书、红皮书、"一文讲透 DDD"的博客都不缺我一份。但我翻完发现两个问题：讲概念的太多，讲判断的太少；讲成功的太多，讲代价的太少。"聚合是一致性边界"谁都会说，难的是判断"库存到底该不该进订单聚合""这个一致性值得用最终一致换吗"——这些没有标准答案，只有取舍依据。
所以我给自己定了四条写法规矩，也意味着我主动放弃了一些东西：①不抄书，每个概念配真实场景，于是放弃了"把定义讲全"的体面；②给数字（行数、耗时、团队规模），放弃了含糊的"显著提升"；③给代价，每个方案说清"你放弃了什么"，放弃了只写优点的爽文感；④给可复制模板，代码直接能改着用。这个系列的价值，一半在收益，一半在代价。
四、按路线图系统学，还是零散跳读？
同样这 11 篇，两种读法获得感差出一整个量级。
零散跳读的人，往往是"点开收藏、合上就忘"：名词记了一堆（聚合、限界上下文、六边形），真到建模判断还是拍脑袋；偶尔抄个开源目录，三个月后系统更乱；案例看了个热闹，换到自己业务就不会用；等读到第 10 篇的误区，前面早踩完坑了。
按路线图系统学的人，第一步就先定位自己是哪类读者、痛点是什么，然后沿着对应路径走：先划边界再碰代码、规则内聚进模型、三个真实案例照练、最后用路线图和体检清单对账。差别不在"又懂了几个词"，而在"能对自己的系统下手了"。
💡我的设计笔记 · 二
我踩过的最贵的一坑，恰恰是在写这个系列时差点重蹈的：又滑回"名词复述"。
有一版大纲，我按教科书顺序从"什么是实体"讲起，写到第 3 篇才进案例。自己读一遍就发现不对——这和我批评过的资料有什么两样？读者看完还是不会动手。于是我推倒重来，把"判断"和"代价"前置，每个概念都绑一个会咬人的真实场景。
这也引出一个我反复强调的点：DDD 是结果，不是动作。照着开源项目抄一套
domain / application / infrastructure / interfaces包名，不会自动获得领域模型；充血模型不会因为文件被放进domain目录就突然有行为。检验有没有真 DDD，只有一个标准——找一条核心业务规则，看它能不能在唯一一个方法里被找到。
五、怎么读不踩空：一张收藏卡
把上面说的压缩成三步，再配一份自测清单，方便你读之前先给自己定个位：
三步很简单：① 先定位你是哪类读者（A 不敢重构 / B 听过没落地 / C 想系统学）；② 选一条对应路径，每条路都有明确终点，读到终点就能合上；③ 定一个终点，无非三件事之一——画出系统的边界、说清一处建模的取舍、知道第一步改哪个类。如果读完只是"又认识几个名词"，说明还在零散跳读，回到第 ② 步重走。
为了让你读得顺，整个系列有几条固定约定，先说在前面：
- 代码均为 Java，领域模型采用充血模型风格（不是只有 getter/setter 的贫血类）；
- 领域事件命名使用过去时（
OrderCreated、OrderPaid），一眼能看出是"已经发生的事"； - 文中提到的"上下文"如无特殊说明，均指"限界上下文"；
- 各篇之间用篇号引用（如"见 04 篇"），不用链接，方便整体复制发布，也方便你跳读后回翻。
六、我为什么要写这个系列（本篇小结）
回到开头那个问题。我写这个系列，不是因为 DDD 资料不够多，恰恰相反——正是因为太多资料停在名词，太少资料停在判断与代价，才需要一个"写给不敢重构的人"的版本。
11 篇走完，我希望你合上书的状态不是"知道了 DDD 有哪些名词"，而是能对着自己的系统画出边界、说出取舍，并且知道第一步该干什么。这篇导读就是那个起点：先想清楚自己是哪类读者、该走哪条路，剩下的，跟着路线一篇篇走即可。
系列目录
| 篇 | 主题 | 一句话 |
|---|---|---|
| 00 | 系列导读 | 本文：这条学习路线怎么走，三类人怎么读 |
| 01 | 为什么需要 DDD | 规则副本的代价与三条原则 |
| 02 | 战略设计（上） | 子域三分法、事件风暴、通用语言表 |
| 03 | 战略设计（下） | 限界上下文与六种上下文映射模式 |
| 04 | 战术设计（上） | 实体、值对象、聚合的建模与三条铁律 |
| 05 | 战术设计（下） | 领域服务、领域事件、仓储与工厂 |
| 06 | 架构模式 | 四层架构、六边形架构与依赖倒置 |
| 07 | 实战案例一 | 电商订单系统：聚合与事件驱动建模 |
| 08 | 实战案例二 | 银行转账：跨聚合的最终一致性 |
| 09 | 实战案例三 | 40 万行单体如何按上下文渐进拆分 |
| 10 | 落地与误区 | 六步路线图、七个高频坑、体检清单 |
下一篇：01 · 为什么需要 DDD—— 先做个五分钟实验：找一条你最有把握的业务规则，全局搜索它，数数在你的代码里写了多少遍。
关于作者
技术原点（YuandianIT）
- 985 计算机硕士，十年一线研发经历，先后在头部互联网公司做交易与履约，现于金融行业负责信贷核心、风控与账务系统的架构设计
- 累计面试近千人，带过 50+ 新人，长期负责技术团队的技术选型与架构评审
- 关注方向：复杂业务系统建模（DDD / 事件驱动 / 一致性设计）与AI 工程化落地
- 写作原则：只写自己动手做过的，只给能落地的结论，方案必须带代价
我信一句话：架构的优劣不在图上，在第三次需求变更时的手感上。
关于技术原点
始于技术，归于原点—— 👉https://yuandianit.com
技术原点是一个基于Spring Boot 3 + Vue 3前后端分离的自有技术平台，把「内容创作 + 付费专栏 + AI 辅助 + 资源交易」完整跑通——不是一个博客 Demo：
| 能力 | 说明 |
|---|---|
| 📝 文章系统 | Markdown 创作、分类标签、归档时间线、阅读量 / 点赞 / 收藏、关键词搜索 |
| 📚 Wiki 知识库 | 专栏化知识库、目录树导航、整册解锁 ——本 DDD 系列会整理成册放在这里 |
| 🤖 AI 助手 | 接入智谱 / OpenAI / 通义千问 / DeepSeek 多模型，支持 SSE 流式追问 |
| 💰 付费阅读 | 四级阅读门禁与付费专栏，支持单篇与整册 |
| 🛒 社区商城 | 源码与服务商品、微信 Native 扫码支付、订单与下载鉴权 |
| ⚙️ 后台管理 | 内容与用户管理、sa-token 权限、操作日志、定时任务、Knife4j 接口文档 |
为什么要到平台上读这个系列？
- 代码和图都在线渲染：架构图、代码高亮、一键复制，比看截图舒服；
- 读到不懂的地方直接问 AI：平台内置多模型 AI 助手，可以就某一篇继续追问，不必等我在评论区回；
- 成册阅读：系列在平台上按 Wiki 专栏组织，目录树跟随，适合系统学一遍；
- 平台本身就是源码：文章里讲的依赖倒置、事件驱动、支付闭环、AI 流式对话，都能在平台源码里找到真实落地——理论和实现互为注解。
👉立即访问：https://yuandianit.com