软件工程 on 方糖猫Blog

十年前泡论坛啃书，现在问 AI：软件知识的分层与获取地图

Mon, 28 Sep 2026 16:00:00 +0800

十年前泡论坛啃书，现在问 AI：软件知识的分层与获取地图

先想象一个具体的任务：你要从零做一个秒杀下单系统。

如果是 2015 年，你的路径大概是这样的：买《深入理解 Nginx》《Redis 设计与实现》，泡博客园和 ITEye，搜"秒杀系统架构"找到几篇大厂的分享 PPT 如获至宝，照着 CSDN 上的帖子抄一段 Nginx 配置，跑不通就去 QQ 群里问。一个消息队列的选型，可能要在论坛里翻几十页帖子。

如果是 2026 年，你打开 AI 问一句：“帮我拆解一个秒杀系统的技术选型和坑。“十秒钟，一份看起来像模像样的方案就出来了。

然后呢？然后你照着 AI 给的代码配 Spring Boot，启动报错——它引用的包名是 Spring Boot 2 的。你问它 Redis 最新版本怎么配，它给你的参数三年前就废弃了。

渠道换了三代，踩的坑是同一个：渠道选错，往往不是信息不够，而是拿错了知识层次。这篇文章想讲清楚两件事：

软件知识分层，每一层有各自唯一靠谱的获取渠道；
从"论坛时代"到"AI 时代”，每一层的渠道具体是怎么变迁的。

一、Spring Boot 和 Netty，其实是两个层面的东西

学习清单上它们常常排在一起：“Spring Boot、Redis、MQ、Nginx、Netty。”

但如果看它们各自真正难的部分，这五个名字其实落在四个不同的层次上：

技术	它真正难的部分	属于哪层
Nginx、Netty	Reactor 模型、epoll、零拷贝、内存管理	贴着操作系统网络的底层组件，核心知识半衰期 10 年+
Redis、MQ（Kafka/RocketMQ）	数据结构、持久化策略、副本协议、消息语义	中间件，核心知识半衰期 5~8 年
Spring Boot	自动装配、约定优于配置、生态整合	应用组装框架，半衰期 3~5 年，小版本还在月月变
用上面这些搭一个秒杀系统	流量整形、幂等、分布式事务、降级预案	方案层，跟着业务实践走，没有教材，只有案例

层次不同，学法就不同：试图"背"Spring Boot 的配置（该查不背），或者试图靠刷博客学懂 Netty 的 EventLoop（该啃源码），都是拿错了工具。层次错位，是学习效率低的第一大原因。

二、四层知识，四个时代的入口

把上面的分层展开，逐层对比"过去去哪获取"和"现在去哪获取”：

原理层：Reactor、CAP、B+ 树、TCP

过去：经典书和论文是唯一入口。《UNIX 网络编程》《TCP/IP 详解》摆在桌上，啃不动就是啃不动，没人能救你。这层知识获取的瓶颈从来不是"找不到"，而是"读不懂"。

现在：书还是那批书——原理层十几年不变，没有新书可写。但多了一件过去不存在的东西：AI 是随问随答的讲解员。“用大白话解释 Reactor 和 Proactor 的区别”、“CAP 里的 P 为什么必须满足”、“这段 epoll 代码为什么这么写”——过去需要一个导师领着啃的东西，现在可以按你自己的水平反复讲。这大概是 AI 对学习方式最大的真实贡献：它消灭了原理层的"读不懂"。

组件层：Netty 的 EventLoop、Redis 的持久化、Kafka 的副本协议

过去：官方文档（英文，劝退）+ 源码硬啃 + 少数系统化的书（《Redis 设计与实现》《Netty 权威指南》《Kafka 权威指南》）。肯读源码的人和不读的人，差距就在这一层拉开。

现在：锚点没变——官方文档和源码仍然是这一层唯一的事实来源。变的是门槛：把 NioEventLoop 的一段源码贴给 AI 问"这段在干嘛"，比自己在调用栈里迷路快十倍。书的意义也变了：不再是唯一的系统材料，而是帮你建立地图——地图有了，细节让 AI 陪你在源码里走。

各组件的锚点，顺手列一下：

Spring Boot：spring.io 的官方 Guides + Reference；版本变化看 GitHub release notes
Redis：redis.io 官方文档，每个命令一页带复杂度说明，质量极高
Kafka：官方文档的 Design 章节，分布式系统教学级材料，值得全文读
RocketMQ：GitHub 仓库里的架构文档，配合 DefaultMQProducer 源码读一遍发送流程
Nginx：nginx.org 指令文档是"查"的，不是"学"的；架构思想看《深入理解 Nginx》
Netty：官方 User Guide 很短，真正的教材是 NioEventLoop 源码本身

版本层：Spring Boot 3 的配置项、Redis 7 的新命令

过去：本来就该看官方 release notes，但很多人不看——踩了坑再去搜博客，搜到别人踩过的同一个坑。

现在：这一层是唯一没有被 AI 改善、反而被 AI 污染的层。AI 有知识截止日期，且会一本正经地编造不存在的配置项和 API。它记忆里的版本知识只能当初稿，不能当答案。正确姿势有两种：一是回归原始动作，直接去官方文档和 release notes 抄；二是把官方文档页面喂给 AI 当上下文再提问（或用 Context7、DeepWiki 这类把最新文档索引给 AI 的工具），让 AI 基于真实文档回答，而不是基于记忆编造。

一句话：版本层的知识不要"学"，要"查"，唯一权威是官方文档。

方案层：秒杀、订单幂等、分布式事务

过去：这是最难获取的一层。官方文档不管组合，书上没有，只能靠大厂技术博客、QCon/ArchSummit 的大会 PPT、以及口口相传。当年能拿到一份大厂秒杀架构的分享 PPT，如获至宝不是修辞，是事实。

现在：大厂博客依然是主力（地址整理在第四节），但增量有两个：

成熟的开源脚手架——mall、RuoYi 这类 Star 数高、持续更新的项目，看它们怎么把组件接起来、怎么处理幂等和分布式事务。重点看 issue 区，坑都在那里。
AI 能做方案 review——把你的设计贴给它问"这个链路哪里会丢消息"，它能列出你该检查的清单。它给出的方案未必对，但它给出的"检查清单"通常很全。

还有一条没变过：看十篇方案不如自己搭一遍。用 Docker Compose 把 MySQL + Redis + RocketMQ + Nginx 拉起来，写一个下单扣库存接口，把消息丢失、缓存穿透、重复消费全踩一遍。踩过的坑才是你的方案。

三、把例子走完：秒杀系统的四层拆解

回到开头的任务，把"做一个秒杀系统"拆到四层，每层的获取动作清清楚楚：

层	秒杀系统里对应的问题	2015 年的动作	2026 年的动作
原理层	为什么用队列削峰（流量整形）；超卖的本质是并发控制	啃书，啃不动就放弃	书 + AI 讲到懂为止
组件层	Redis Lua 扣库存的原子性；RocketMQ 事务消息	官方文档 + 源码硬啃	文档源码仍是锚点，AI 当导读
版本层	Spring Boot 3 整合 Redis 的依赖坐标；RocketMQ 5.x 客户端配置	踩坑后搜博客	官方文档抄，或喂文档给 AI
方案层	整条链路怎么组装、降级预案怎么定	大厂 PPT + 口口相传	大厂博客 + 开源脚手架 + AI review + 自己搭

注意一个细节：四层里只有原理层和方案层的"获取"被 AI 真正改变了；组件层是门槛降低，版本层反而要多一道验证。AI 没有改变知识的层次结构，只改变了每一层的获取效率。

四、趋势在哪看

趋势是方案层之上的东西：不告诉你 API 怎么写，但告诉你行业在往哪走。

过去：书和杂志的序言、线下大会、以及"听说隔壁公司在用什么"。信息慢，但噪声也小。

现在：信号源多了，按信号强度排序——

GitHub Trending + Awesome 系列：trending 看热度，awesome-xxx 看生态成熟度。一个方向的 awesome 列表两年没更新，基本就是凉了。
顶级会议议题表：KubeCon、QCon/ArchSummit、Spring I/O、AWS re:Invent。连续三年都有专场的话题，已经不是趋势，是现实。
ThoughtWorks 技术雷达：半年一期，敢说"暂缓"，比只会吹捧的报告值钱。
年度调查：Stack Overflow / JetBrains 开发者报告。“实际在用什么"和"媒体在吹什么"的差值，就是泡沫。
大厂技术博客：他们踩过的坑，就是你两年后的日常。常用入口（RSS 为发文前实测可用）：

国内：

团队	地址	RSS / 订阅方式
美团技术团队	tech.meituan.com	RSS
阿里（淘天/阿里云等）	阿里云开发者社区	无官方 RSS，可用 RSSHub 生成
字节跳动技术团队	掘金官方号、开源官网博客	无官方 RSS，可用 RSSHub 生成
腾讯云开发者	cloud.tencent.com/developer	无官方 RSS

国外：

团队	地址	RSS
Netflix	netflixtechblog.com	RSS
Meta Engineering	engineering.fb.com	RSS
AWS	aws.amazon.com/blogs	RSS
Uber	uber.com/blog/engineering	无公开 RSS
Google Developers	developers.googleblog.com	页面提供 Atom 订阅

国内团队不提供 RSS 的居多（内容越来越多迁到公众号和自家社区），两个补救办法：用 RSSHub 把社区页面转成 RSS；或者干脆不订阅，按季度扫一遍历史文章列表——好内容不怕晚三个月。

无论渠道怎么变，趋势这东西季度性地扫一眼就够了。天天刷只会制造焦虑。真正值得追的趋势，三个月后它还在。

五、AI 时代真正改变的三件事

把全文收拢成三句话：

原理层的获取成本坍缩了。 过去最大的瓶颈"读不懂"被 AI 消灭了——这是学习方式上最深刻的改变，没有之一。
验证变得比知道重要。 AI 会编，尤其在版本层。靠谱的工作流只剩三步：AI 讲原理 → 官方文档定版本 → 跑起来验证。跑不通，把报错喂回去让它修。AI 时代最值钱的技能不是"知道答案”，而是"会写验证答案的实验"。
提问质量 = 知识杠杆率。 “Redis 怎么用"和"Spring Boot 3.2 + Redis 7，Lettuce 客户端，缓存用户会话 TTL 30 分钟，缓存穿透怎么处理，给最小示例”——后者的答案质量是前者的十倍。你掌握的原理层知识越多，问题就描述得越精确，AI 的产出就越好。底层知识没有贬值，它变成了杠杆。

获取渠道换了三代：书 → 博客论坛 → 公众号 → AI。不变的是知识的分层，和你对"什么知识值得花时间"的判断力。AI 让"知道"变得廉价，让"验证"和"判断"变得昂贵——未来拉开差距的，不是谁知道得多，而是谁分得清：哪句话该信 AI，哪句话必须去翻官方文档。

《领域驱动设计·精简版》详解：零基础读懂 DDD 的核心概念

Sat, 29 Jul 2023 14:00:00 +0800

《领域驱动设计·精简版》详解：零基础读懂 DDD 的核心概念

DDD 要回答的问题是：

软件是为了解决现实业务问题而存在的，可为什么代码写着写着，就和业务彻底脱节了？

Eric Evans 的答案是：问题出在"模型"上。业务在领域专家脑子里，代码在程序员手里，中间隔着层层"翻译"，每翻译一次就失真一次。DDD 的全部内容，就是围绕"如何建立一个好模型、并让模型直接活在代码里"展开的。

本文面向从未接触过 DDD 的读者，按全书结构逐章展开，配合图解和实例，帮你建立完整的知识地图。

第 1 章简介：软件为什么会偏离领域

领域与领域模型

**领域（Domain）**就是软件要解决的那个现实问题。做银行系统，金融业务就是领域；做空中交通监控，航线和飞行就是领域。

书里用了一个类比：造汽车。工人们各自负责某个零件，但如果没人理解整车，造出来的只是一堆零件的集合体，不是一辆好车。软件也一样——你不能在对金融业务一无所知的情况下写出好的银行软件。谁懂业务？不是架构师，不是分析师，是领域专家（银行的业务人员、空管的调度员）。

但领域知识是海量而杂乱的，不可能全部塞进软件。我们需要从中建立抽象——即领域模型（Domain Model）：

模型不是一张图，也不是专家脑子里的全部知识，而是"经过严格组织并进行选择性抽象的知识"。

建模意味着取舍。银行软件会记录客户的住址，但绝不会记录客户眼睛的颜色——前者是业务需要的，后者不是。选择保留什么、放弃什么，正是建模的核心工作。

书里的案例：空中交通监控系统

全书反复使用同一个例子：空中交通监控系统。飞机（Aircraft）按计划航线（Route）飞行，航线由一系列定位点（Fix）组成，每个定位点是一个三维坐标（3DPoint：经度、纬度、海拔）。系统接收雷达数据，计算飞机的真实飞行轨道，发现两架飞机航线可能交叉时向管制员报警。

最初的设计里，Route 直接关联 3DPoint，后来团队发现：地面屏幕上显示的航线其实只需要二维投影，于是模型被重构为 Route 关联 2DPoint——模型随理解的加深而演进，这正是 DDD 强调的动态过程。

第 2 章通用语言（Ubiquitous Language）

翻译是万恶之源

开发人员和领域专家说着两种语言：

开发人员满脑子是类、方法、继承、多态、框架；
领域专家满口是飞机、航线、海拔、偏航告警。

于是每次沟通都在"翻译"：开发人员把业务术语翻译成技术概念去写代码，再把技术实现翻译回业务语言去汇报。每一次翻译都丢失信息，错误理解就这样悄悄积累。更糟的是，很多时候团队连"翻译错了"都发现不了，直到软件上线才爆发。

用模型当语言的骨架

DDD 的核心原则之一：使用一种基于模型的语言进行所有交流——讨论用它，文档用它，代码里的类名、方法名也用它。因为语言贯穿所有交流形式，所以叫通用语言（Ubiquitous Language）。

flowchart LR
    subgraph 传统方式["传统方式：靠翻译，层层失真"]
        E1["领域专家<br/>（业务行话）"] -->|需求翻译| A1["分析师文档"]
        A1 -->|设计翻译| D1["开发人员"]
        D1 -->|代码实现| C1[("代码<br/>（第三套术语）")]
    end
    subgraph DDD方式["DDD 方式：一种语言贯通"]
        E2["领域专家"] <==>|"通用语言<br/>（基于领域模型）"| D2["开发人员"]
        D2 --- C2[("代码 = 模型<br/>术语完全一致")]
        E2 --- C2
    end

实例：空管系统里有个概念叫"偏航告警"。如果代码里叫 YawDeviationWarningProcessor，而管制员嘴里叫"偏航告警"，需求评审时大家讨论的是 A，代码里实现的是 B，三个月后没人能对上号。按 DDD 的做法，团队约定统一叫"偏航告警（RouteDeviationAlert）"，类名、数据库表、会议讨论全部用同一个词——模型和代码之间不再存在翻译层。

通用语言不是一次定稿的，它随模型的演进而演进：当你发现某个词说不清一件事，往往不是表达问题，而是模型有问题——这就是重构的信号。

第 3 章模型驱动设计（Model-Driven Design）

这是全书篇幅最大的一章，讲模型怎么落地成代码。Eric Evans 提供了一套标准化的"构造块"（Building Blocks）。

分层架构

先把领域层隔离出来，别让业务逻辑散落在界面和数据库代码里：

flowchart TD
    UI["用户界面层<br/>展示信息、接收输入"]
    APP["应用层<br/>协调任务、编排流程<br/>（很薄，不含业务规则）"]
    DOM["领域层<br/>★ 业务概念、业务规则、业务状态<br/>模型的家"]
    INFRA["基础设施层<br/>持久化、消息、框架支撑"]
    UI --> APP --> DOM
    INFRA -.支撑.- DOM

关键原则：领域层不依赖界面，不被基础设施污染。判断标准很简单——把界面整个换掉（比如从网页换成 App），领域层应该一行都不用改。

七个构造块

flowchart LR
    subgraph 领域层["领域层的构造块"]
        direction TB
        E["实体 Entity<br/>有身份，有生命周期"]
        VO["值对象 Value Object<br/>无身份，不可变"]
        S["服务 Service<br/>不属于任何对象的操作"]
        M["模块 Module<br/>按概念分组"]
        AGG["聚合 Aggregate<br/>一致性边界 + 聚合根"]
        F["工厂 Factory<br/>封装复杂创建"]
        R["资源库 Repository<br/>封装查询与重建"]
        AGG --> E
        AGG --> VO
        F --> AGG
        R --> AGG
    end

① 实体（Entity）：靠"身份"区分

有些对象，即使属性全变了，它还是"它"。一架飞机换了涂装、换了座椅布局，航班号 CA1234 还是那架飞机。实体由身份标识（ID）定义，而不是属性。人也是典型的实体——同名同姓的两个人依然是两个人。

② 值对象（Value Object）：靠"属性"区分

有些对象没有身份，只描述"是什么"。地址"北京市海淀区某路 1 号"就是值对象：两个地址属性完全相同，就是同一个地址，可以互换、可以共享。值对象应该是不可变的——要改就新建一个。

新手最常见的错误是把一切都建成实体。书里建议：优先考虑值对象，只有当"身份"确实重要时才用实体——值对象更简单、更安全、性能更好。

③ 服务（Service）：无家可归的操作

有些操作天然不属于任何实体或值对象。比如"转账"：钱从 A 账户到 B 账户，这个操作该挂在 A 身上还是 B 身上？都不合适。把它做成一个领域服务 TransferService。判断标准：操作的概念属于领域，但它本身是无状态的。

④ 模块（Module）：高内聚、低耦合的分组

把概念上紧密相关的类放进同一个模块。模块名也应该进入通用语言——当团队说"这是计费模块的事"，所有人都知道边界在哪。

⑤ 聚合（Aggregate）：一致性的边界

对象之间关系复杂时，改一个对象可能牵连一片。聚合的解法是：把关联紧密的对象圈进一个边界，选一个实体做"聚合根"（Aggregate Root），外部只能通过根访问内部对象。

书里的例子：客户（Customer）是聚合根，地址（Address）、联系人是内部对象。外部想要地址？找客户要，拿到的是一个拷贝，不能直接改——所有对聚合内部的修改都经过根把关，不变量（invariant）就有了守护者。

flowchart TD
    subgraph 聚合边界["聚合边界"]
        ROOT["客户 Customer<br/>（聚合根）"]
        ADDR["地址 Address"]
        CONTACT["联系人 Contact"]
        ROOT --> ADDR
        ROOT --> CONTACT
    end
    OUT["外部对象"] -->|"只能持有根的引用"| ROOT
    OUT -.->|"禁止直接访问"| ADDR

⑥ 工厂（Factory）：封装"怎么造"

创建一个复杂聚合涉及大量知识：内部结构、对象间关系、初始规则。如果让调用方自己 new 再拼装，等于"给你塑胶、橡胶、金属、硅，自己组装一台打印机"——组装知识泄漏到了所有调用点。工厂把创建逻辑收进一处，客户只要说"我要一个完整的客户聚合"。

⑦ 资源库（Repository）：封装"怎么找"

对象创建后存进数据库，之后要用时再取出来。资源库给领域对象提供一个"像集合一样"的查询接口（findById、findByName），把 SQL 和 ORM 细节全部藏在背后。领域代码面对的好像是一个内存中的对象集合，至于底下是 MySQL 还是 MongoDB，领域层不关心。

三者分工一句话：工厂管出生，资源库管找回，聚合管活着时的一致性。

第 4 章面向深层理解的重构

模型不是一次画对的。随着对业务理解的加深，团队会不断发现"原来的模型表达不了新需求"。DDD 的态度是：持续重构，并且专门朝"深层理解"的方向重构——不是消除代码重复那种技术重构，而是当领域专家随口说出一个新概念时，敏锐地意识到"这个词值得成为模型里的一等公民"。

书里称之为凸现关键概念：把隐晦的、散落在各处的业务规则，提炼成显式的类和方法。

实例：空管系统最初把"两机航线交叉判断"写在一段几百行的过程代码里。重构后，团队把它提炼成 FlightPathConflict 对象和 conflictsWith() 方法——业务规则从"代码的副作用"变成了"模型中可以直接讨论的概念"。测试可以单独写，管制员和开发可以用同一个词讨论它。

第 5 章保持模型一致性：大型项目的生存法则

前面讲的都是"一个团队、一个模型"的情况。企业级项目有多个团队并行开发，理想中"全公司统一的大模型"实际上根本维持不住——每个团队都知道自己后院里有什么，但对其他地方一无所知，改一处就可能破坏别人的功能。

Eric Evans 的结论很反直觉：不要试图维持一个注定四分五裂的大模型，而是有意识地把大模型拆成几个小模型，每个模型有清晰的边界。

界定的上下文（Bounded Context）

每个模型只在一个明确的边界内有效，这个边界叫界定的上下文。同一个词在不同上下文里可以有完全不同的含义：

实例：电商系统里"商品"这个词——

在销售上下文里，它有价格、促销、库存；
在物流上下文里，它只有重量、体积、包装方式；
在售后上下文里，它只有保修期和维修记录。

试图用一个统一的 Product 类满足三个团队，结果一定是个臃肿的"上帝类"。承认三个上下文各有各的"商品"，反而各自清晰。

flowchart LR
    subgraph 销售上下文["销售上下文"]
        P1["商品：价格/促销/库存"]
    end
    subgraph 物流上下文["物流上下文"]
        P2["商品：重量/体积/包装"]
    end
    subgraph 售后上下文["售后上下文"]
        P3["商品：保修期/维修记录"]
    end
    P1 <-->|"上下文映射<br/>（翻译）"| P2
    P2 <-->|"上下文映射"| P3

上下文之间的六种关系模式

上下文不能各自为战，它们之间需要集成。书里给出了一组模式，按"两个团队的合作意愿和权力关系"来选择：

flowchart TD
    Q{"两个上下文如何共处？"}
    Q -->|"愿意深度共享代码"| SK["共享内核 Shared Kernel<br/>划出一块双方都依赖的小模型<br/>共同维护，改动需协商"]
    Q -->|"上下游关系明确"| CS["客户-供应商 Customer-Supplier<br/>上游按下游需求规划开发"]
    Q -->|"下游无力影响上游"| CF["顺从者 Conformist<br/>直接采用上游模型，放弃翻译"]
    Q -->|"要对接脏乱差的遗留系统"| ACL["防崩溃层 Anticorruption Layer<br/>建一层翻译，把污染挡在门外"]
    Q -->|"集成成本 > 收益"| SW["独立方法 Separate Ways<br/>干脆不集成，各做各的"]
    Q -->|"一个系统被多方集成"| OHS["开放主机服务 Open Host Service<br/>定义标准协议，免去一对一翻译"]

几个重点：

上下文映射（Context Map）：把所有上下文和它们之间的关系画在一张图上。这张图是大型项目里最重要的架构文档——它让每个团队都看清"我的边界在哪、我和谁有契约"。
共享内核：两个团队共用一小部分模型（比如通用的客户标识）。共享意味着牵一发而动全身，所以内核要尽量小。
防崩溃层（ACL）：对接遗留系统时，遗留模型往往概念混乱。如果直接在自己的代码里用它的概念，好模型会被污染。ACL 是一层专门的翻译器：外面进来的是遗留概念，翻成本地模型再入内。遗留系统的"腐烂"被挡在层外。
顺从者 vs 防崩溃层：下游对上游没有话语权时，要么顺从（直接用上游模型），要么自建翻译层。前者省成本，后者保纯洁——取决于上游模型的质量。
开放主机服务：当你的系统要被十个团队集成时，给每个团队定制翻译层会把你拖垮。定义一套标准协议（比如一套公共 API），所有集成方遵循它。

精炼（Distillation）：找到核心域

大模型拆小之后还有一个问题：哪里最值得投入最优秀的人力？答案是核心域（Core Domain）——代表领域本质、构成业务竞争力的那一小块。

书里的例子非常精彩：空中交通监控系统里，“航线"看起来无处不在，但它其实是个普通概念，很多领域都有航线。系统真正的"心脏"是基于雷达数据实时计算飞行轨道、发现航线交叉并告警的那个模块——这才是这套系统区别于任何普通航线系统的本质，也是最该投入最强团队、精雕细琢的地方。其余部分（普通子域）可以外包、可以买现成组件、可以交给初级团队。

战略层面的启示：不是所有代码都值得写好。把最好的资源压在核心域上，其他地方"够用就行”。

第 6 章专访 Eric Evans

书末是 InfoQ 对 Eric Evans 的访谈，几个观点值得记住：

DDD 不是新方法，而是对二十年来优秀团队实践的系统化总结；
DDD 与敏捷并不冲突，恰恰相反——没有好模型的敏捷团队，重构会越来越吃力；
DDD 的难点不在技术，在于团队是否愿意持续地和领域专家坐在一起打磨模型和语言。

全书总结：一张 DDD 知识地图

mindmap
  root((领域驱动设计<br/>DDD))
    核心思想
      软件是领域的映射
      模型是选择性抽象
      模型直接活在代码里
    通用语言
      一种语言贯穿讨论与代码
      说不清 = 模型有问题
    模型驱动设计
      分层架构
        界面层
        应用层
        领域层
        基础设施层
      构造块
        实体 = 身份
        值对象 = 属性 + 不可变
        服务 = 无状态操作
        聚合 = 一致性边界
        工厂 = 管创建
        资源库 = 管存取
    深层理解
      持续重构
      凸现关键概念
    保持模型一致性
      界定的上下文
      上下文映射
        共享内核
        客户-供应商
        顺从者
        防崩溃层
        独立方法
        开放主机服务
      精炼出核心域

DDD 最打动人的地方在于，它把软件开发从"写代码"重新定义为"持续理解业务、并把理解精确表达出来“的过程。代码只是表达模型的介质，模型才是资产。

如果你是零基础读者，建议按这个顺序消化：先吃透"通用语言”（它不需要任何技术背景，却能立刻改善团队协作），再掌握七个构造块（写代码时随时对照），最后在有大型项目或微服务需求时再深入"界定上下文"那一套——你会发现近年火热的微服务拆分方法论，思想源头正是这本书的 Bounded Context。

《领域驱动设计》精简版：一张图看懂 DDD，引用开源 ddd-demo

Thu, 27 Jul 2023 20:00:00 +0800

《领域驱动设计》精简版：一张图看懂 DDD，引用开源 ddd-demo

这份笔记基于 Eric Evans 的《领域驱动设计》以及 Vaughn Vernon 的《实现领域驱动设计》《领域驱动设计精粹》，结合日常工程实践做了补充。文中完整代码实现参考开源项目 soulnew/ddd-demo，可直接克隆运行。

一、为什么需要 DDD？

传统分层架构（Controller → Service → DAO）的问题：

问题	表现
贫血模型	`Service` 里全是 if/else，Entity 只有 getter/setter
语义泄漏	业务术语被翻译成 `status = 1`，新人读不懂
边界模糊	一个 `OrderService` 同时处理库存、支付、物流
复用困难	同样叫“用户”，在会员、权限、订单里含义不同

DDD 的核心主张：让软件结构对齐业务领域，用业务语言写代码，用边界保护领域模型。

二、一张图：DDD 战略-战术全景

mindmap
  root((领域驱动设计 DDD))
    战略设计 Strategic Design
      领域 Domain
      子域 Subdomain
        核心域 Core
        支撑域 Supporting
        通用域 Generic
      限界上下文 Bounded Context
      上下文映射 Context Mapping
        合作关系 Partnership
        共享内核 Shared Kernel
        客户-供应商 Customer-Supplier
        遵奉者 Conformist
        防腐层 ACL
        开放主机服务 OHS
        发布语言 PL
        各行其道 Separate Ways
    战术设计 Tactical Design
      实体 Entity
      值对象 Value Object
      聚合 Aggregate
      领域服务 Domain Service
      仓储 Repository
      工厂 Factory
      领域事件 Domain Event
      应用服务 Application Service
    统一语言 Ubiquitous Language
    分层架构 Layered Architecture
      用户界面层 UI
      应用层 Application
      领域层 Domain
      基础设施层 Infrastructure

记忆口诀：先战略（划边界），后战术（建模型），全程讲“统一语言”。

三、战略设计：先画地图，再打仗

3.1 领域 = 问题空间 + 解决方案空间

graph LR
    A[问题空间<br/>Problem Space] --> B[领域 Domain<br/>业务要解决的问题]
    B --> C[子域 Subdomain<br/>可独立讨论的业务板块]
    C --> D[核心域 Core Domain<br/>竞争优势]
    C --> E[支撑域 Supporting<br/>定制但非核心]
    C --> F[通用域 Generic<br/>可外购/复用]
    D --> G[解决方案空间<br/>Solution Space]
    E --> G
    F --> G
    G --> H[限界上下文 Bounded Context<br/>一个模型只在一个上下文内有效]

示例：在线医疗平台

子域	类型	说明
问诊	核心域	核心竞争力，需精研模型
处方	支撑域	受监管约束，需定制但非差异化
支付	通用域	可直接对接微信/支付宝
消息通知	通用域	短信/推送可用第三方

3.2 限界上下文 Bounded Context

定义：限界上下文是领域模型能够保持一致性和完整性的显式边界。在边界内部，每个业务术语、概念、规则都有精确且唯一的含义；同一概念在不同限界上下文中可以拥有不同定义。它是 DDD 战略设计中保护模型不被语义污染的最小单元。

同一个业务名词，在不同上下文里含义可能完全不同。DDD 用“限界上下文”给模型画边界。

graph TB
    subgraph 商品上下文 Product Context
        P1[商品 = SKU + 价格 + 库存]
    end
    subgraph 订单上下文 Order Context
        P2[商品 = 快照 + 购买时价格 + 数量]
    end
    subgraph 物流上下文 Logistics Context
        P3[商品 = 重量 + 体积 + 易碎标识]
    end
    subgraph 营销上下文 Marketing Context
        P4[商品 = 卖点 + 优惠券适用规则]
    end
    P1 -.->|映射| P2
    P1 -.->|映射| P3
    P1 -.->|映射| P4

关键认知：不要追求“一个全局统一的数据模型”，要在上下文内部统一，在上下文之间显式映射。

3.3 上下文映射模式

定义：上下文映射模式是 DDD 中用于描述不同限界上下文之间集成关系与协作方式的战略模式集合。由于每个限界上下文都有自己的模型和统一语言，当业务流程跨越多个上下文时，需要通过上下文映射来显式定义它们如何依赖、转换与协作，从而保证边界清晰、演化可控。

graph LR
    A[上下文 A] -->|合作关系<br/>Partnership| B[上下文 B]
    C[上下文 C] -->|共享内核<br/>Shared Kernel| D[上下文 D]
    E[上游 Upstream] -->|客户-供应商<br/>Customer-Supplier| F[下游 Downstream]
    G[强势上游] -->|遵奉者<br/>Conformist| H[下游]
    I[下游] -->|防腐层 ACL| J[外部系统]
    K[开放主机服务 OHS<br/>+ 发布语言 PL] --> L[下游]
    M[上下文 M] -.->|各行其道<br/>Separate Ways| N[上下文 N]

模式	使用场景
合作关系	两个团队互相依赖，共同演进
共享内核	核心模型由双方共同维护，改动需同步
客户-供应商	上游优先服务下游需求，下游有话语权
遵奉者	上游强势（如外部 SaaS），下游无条件接受
防腐层 ACL	隔离遗留系统或外部 API，保护领域模型
开放主机服务 + 发布语言	上游提供稳定 API/协议，供多个下游消费
各行其道	关联微弱，各自独立

3.4 从限界上下文到微服务边界

限界上下文是语义边界——一个模型在这个边界内含义一致；微服务是部署边界——独立代码库、独立数据库、独立发布单元。二者不是一回事，但 DDD 划分微服务边界时，最可靠的起点就是限界上下文。

映射原则

graph LR
    A[业务领域] --> B[识别子域<br/>Core / Supporting / Generic]
    B --> C[定义限界上下文<br/>语义边界]
    C --> D{是否满足<br/>拆分条件？}
    D -->|是| E[一个微服务]
    D -->|否| F[多个上下文合并<br/>或模块化单体]
    E --> G[独立数据库<br/>独立部署<br/>API / 事件交互]

默认规则：一个限界上下文对应一个微服务。

例外情况：

情况	处理
上下文内部模块差异极大（性能、安全、团队）	可进一步拆分，但要保留相同的“统一语言”子空间
多个上下文非常小且高度协作	可合并为一个服务，内部用模块隔离
团队规模小、业务简单	先模块化单体，随演进再拆
强一致事务需求	优先放在同一服务 / 同一数据库内

拆分的启发条件

满足以下任意一条，都可以把限界上下文拆成独立微服务：

独立演进：团队能独立发布，不阻塞他人。
独立伸缩：流量特征不同，例如订单读多写少，库存强一致写频繁。
独立故障域：一个服务故障不应拖垮整个平台。
独立技术栈：某些上下文需要特殊存储（图数据库、时序数据库等）。
合规隔离：支付、医疗、金融数据需要独立部署和审计。

案例：B2C 电商的微服务边界划分

以常见的 B2C 电商为例，演示“子域 → 限界上下文 → 微服务”的完整推导过程。

第一步：识别子域

子域	类型	说明
订单	核心域	下单、状态机、优惠计算
库存	核心域	实时库存、预占、扣减
支付	通用域	对接微信 / 支付宝 / 信用卡
物流	支撑域	运单、轨迹、配送规则
商品	核心域	类目、属性、价格
营销	支撑域	优惠券、满减、秒杀
会员	支撑域	积分、等级、权益

第二步：定义限界上下文与统一语言

同一个业务名词在不同上下文里含义不同，这正是拆分的语义依据。

上下文	“商品”在该上下文中的含义	“订单”在该上下文中的含义
商品上下文	SKU、SPU、类目、主图、售价	无
订单上下文	商品快照（下单时的价格和描述）	聚合根：状态、金额、行项
库存上下文	可售数量、预占数量、仓库	无
物流上下文	重量、体积、易碎标识	发货单、包裹、运单
营销上下文	适用优惠券的商品范围	优惠分摊、实付金额

关键判断：如果两个地方对“商品”的定义和生命周期完全不同，就应分属不同上下文，也倾向于拆成不同微服务。

第三步：映射为微服务

graph TB
    subgraph 微服务边界
        P[商品服务<br/>Product Service]
        O[订单服务<br/>Order Service]
        I[库存服务<br/>Inventory Service]
        PAY[支付服务<br/>Payment Service]
        L[物流服务<br/>Logistics Service]
        M[营销服务<br/>Marketing Service]
        U[会员服务<br/>Member Service]
    end

    O -->|预占库存| I
    O -->|发起支付| PAY
    I -->|OrderPaid 事件| L
    O -->|查询商品信息| P
    O -->|计算优惠| M
    U -->|积分抵扣| O

第四步：选择上下文映射模式

关系	模式	说明
订单 → 库存	客户-供应商 + 最终一致	订单调用库存预占接口；库存发布 `InventoryReserved` 事件
订单 → 支付	开放主机服务 OHS	支付提供标准支付网关 API，多个业务共用
库存 → 物流	发布语言 PL + 领域事件	`OrderPaid` 事件触发物流创建发货单
订单 → 商品	遵奉者 / ACL	商品模型由商品服务定义，订单只保存快照
营销 → 订单	共享内核 Shared Kernel	优惠分摊算法需双方共同维护

常见反模式

反模式	问题	正确做法
按 CRUD 实体拆分	`UserService`、`OrderService`、`ProductService` 只是数据表代理	按业务能力（上下文）拆分，服务内包含完整业务规则
按前端页面拆分	一个页面一个服务	页面是组合层，服务应按领域聚合
过度拆分	一次下单调 20 个接口	先模块化单体，验证边界后再拆
共享数据库	多个服务直接操作同一张表	每个服务拥有自己的数据，通过 API / 事件交互

一句话：微服务边界不是拍脑袋定的，而是从“限界上下文”出发，结合团队、性能、合规、发布节奏再微调的结果。

四、战术设计：在限界上下文里建模型

4.1 核心概念关系图

classDiagram
    class AggregateRoot {
        +Entity root
        +invariant()
    }
    class Entity {
        +identity
        +continuity
    }
    class ValueObject {
        +immutable
        +equality by value
    }
    class DomainEvent {
        +eventId
        +occurredOn
        +payload
    }
    class Repository {
        +save(aggregate)
        +byId(id)
    }
    class DomainService {
        +cross-aggregate logic
    }
    class Factory {
        +create()
    }
    AggregateRoot --> Entity : contains
    AggregateRoot --> ValueObject : contains
    AggregateRoot --> DomainEvent : publishes
    Repository --> AggregateRoot : persists
    Factory --> AggregateRoot : creates
    DomainService --> AggregateRoot : orchestrates

4.2 实体 Entity vs 值对象 Value Object

graph LR
    subgraph Entity
        E1[Order #1001] --> E2[状态变化<br/>待支付 → 已发货 → 已完成]
        E2 --> E3[同一 identity<br/>状态变了还是它]
    end
    subgraph Value Object
        V1[Money amount=100 currency=CNY] --> V2[不可变]
        V2 --> V3[替换即新生<br/>money = money * 2]
    end

判断标准：

如果对象需要被追踪生命周期，有独立身份 → 实体
如果对象只描述属性，换了值就等于换了对象 → 值对象

五、完整设计 Demo：电商订单上下文

完整的代码实现可参考开源项目：

Gitee: soulnew/ddd-demo
https://gitee.com/soulnew/ddd-demo

该项目演示了一个典型的 DDD 工程结构，包括：

领域层：实体、值对象、聚合根、领域服务、领域事件
应用层：应用服务、Command/Query、事务编排
基础设施层：仓储实现、外部 API 适配、消息发布
接口层：Controller / API 入口

建议结合本节的战术概念，重点阅读：

domain/ 下的聚合根如何封装业务规则（如订单状态机）。
application/ 下的应用服务如何编排用例，不写业务规则。
infrastructure/ 下的仓储实现如何把领域模型映射到持久化。

如果你想快速跑通一个最小可运行示例，也可以直接克隆该项目：

git clone https://gitee.com/soulnew/ddd-demo.git

下面只保留一个最小示意图，帮助理解“充血模型”与“贫血模型”的关键差异。

5.1 充血模型 vs 贫血模型对比

贫血模型	充血模型
`OrderService` 里写 `if (status.equals("PAID"))`	`Order.pay()` 自己封装状态机
`OrderEntity` 只有 getter/setter	`Order` 有业务方法，规则集中在领域对象
规则散落在 Service	不变量、状态变更由聚合根保证
持久化即领域模型	持久化是领域模型的投影

核心原则：把“什么样合法”的判断放到领域对象里，应用服务只负责“什么时候调用”。

六、分层架构：代码放哪里？

graph TB
    subgraph 用户界面层 UI/API
        U1[Controller / Handler]
    end
    subgraph 应用层 Application
        A1[Application Service]
        A2[DTO / Command / Query]
    end
    subgraph 领域层 Domain
        D1[Entity]
        D2[Value Object]
        D3[Domain Service]
        D4[Domain Event]
        D5[Repository Interface]
    end
    subgraph 基础设施层 Infrastructure
        I1[Repository Implementation]
        I2[Message Queue]
        I3[Database]
        I4[External API Client]
    end

    U1 --> A1
    A1 --> D1
    A1 --> D3
    D1 --> D2
    D1 -.->|发布| D4
    A1 --> D5
    D5 -.->|由| I1
    I1 --> I3
    A1 -.->|发送| I2
    A1 -.->|调用| I4

依赖方向：UI → 应用 → 领域；基础设施通过接口被领域依赖（依赖倒置）。

层级	职责	不该做的事
UI	接收请求、返回响应	不直接操作 Repository
应用层	编排用例、事务、权限校验	不写业务规则
领域层	业务规则、不变量、状态变更	不依赖框架/数据库
基础设施	持久化、消息、外部调用	不侵入领域规则

七、聚合设计：四条黄金规则

graph TB
    subgraph 聚合根 Order
        O1[Order] --> L1[OrderLineItem]
        O1 --> L2[OrderLineItem]
        O1 --> M1[Money total]
        O1 --> A1[Address shipping]
        O1 --> E1[DomainEvent list]
    end
    subgraph 外部只能通过聚合根访问
        X[其他上下文] -->|byId/order.pay| O1
        X -.->|❌ 不能直接修改| L1
    end

一个聚合只有一个聚合根，外部对象只能引用聚合根 ID。
聚合内部强一致，跨聚合最终一致（用领域事件）。
小聚合优先，大聚合会成性能瓶颈和并发热点。
删除聚合根级联删除其内部对象。

反例：如果把 User 和 Order 放在同一个聚合里，用户每次下单都会锁定整个用户聚合，极端不合理。

八、领域事件：跨聚合/上下文的胶水

sequenceDiagram
    participant O as Order 聚合
    participant E as Event Bus
    participant I as Inventory 上下文
    participant L as Logistics 上下文
    O->>O: order.pay()
    O->>E: publish OrderPaid
    E->>I: consume OrderPaid
    I->>I: 扣减库存
    E->>L: consume OrderPaid
    L->>L: 创建发货单

领域事件的价值：

解耦：Order 不需要知道 Inventory 和 Logistics 的存在。
最终一致：接受短时间不一致，换取可扩展性。
审计：事件日志本身就是业务轨迹。

九、常见反模式与纠正

反模式	现象	纠正
贫血领域模型	Entity 只有字段，Service 全是逻辑	把不变规则和状态变更放回实体
万能聚合	一个聚合包含十几个实体	按业务不变量拆分，跨聚合用事件
数据库驱动建模	先建表，再写代码	先建模，再映射持久化
跨上下文直接引用	Order 直接持有 Inventory 对象	只存 ID，通过 ACL/OHS 交互
应用层写业务规则	`if order.status == ...` 散落在 Service	下放到领域对象
值对象可变	`money.setAmount(100)`	用 final 类 + 不可变字段，替换而非修改

十、什么时候用 DDD，什么时候不用？

flowchart TD
    A[项目是否复杂？] -->|否| B[简单 CRUD 即可]
    A -->|是| C[业务是否快速变化？]
    C -->|否| D[事务脚本 / 简单分层]
    C -->|是| E[团队是否愿意投入统一语言？]
    E -->|否| F[DDD 收益低]
    E -->|是| G[DDD 值得尝试]
    G --> H[从核心域开始<br/>小步迭代]

适合 DDD：

业务复杂、领域专家与开发需紧密协作
核心域需要长期演进
微服务边界模糊，需要战略设计

不适合 DDD：

简单数据录入/展示系统
生命周期短、需求稳定的项目
团队没有领域专家时间投入

十一、实战案例：新项目从 0 到 1 落地 DDD

前面讲的都是概念和 Demo，下面以 在线健身私教平台 FitCoach 为例，把“如何划分领域、子域、限界上下文、微服务，以及如何决策充血/贫血模型、如何裁剪 DDD”串成一条完整思路。

11.1 项目背景与目标

FitCoach 要做一个连接私教与学员的平台，核心能力包括：

学员购买课程包、预约上课时间、查看训练记录
教练管理学员、制定训练计划、记录每次上课内容
运营人员配置课程 SKU、促销活动、处理退款申诉
对接第三方支付、短信推送、以及第三方直播上课工具

业务不算极端复杂，但涉及“课程、预约、课时、计划、会员、支付、营销”多个概念，且预计会快速迭代。这正是 DDD 能帮上忙的地方：先把业务地图画清楚，再决定怎么写代码。

11.2 第一步：识别领域与子域

领域（Domain） 就是整个健身私教业务要解决的问题空间。通过事件风暴或用户旅程，可以识别出以下子域：

子域	类型	判断理由	投入策略
私教课程与预约	核心域	直接决定用户体验和变现效率	投入最好的领域专家和工程师
训练计划与记录	核心域	教练专业能力的载体，差异化关键	与课程域紧密协作演进
会员与教练档案	支撑域	需要定制，但不是竞争壁垒	内部实现，够用即可
支付与财务	通用域	行业通用能力	对接微信/支付宝，封装标准接口
消息通知	通用域	短信/推送/站内信	使用第三方 SaaS
内容（文章/视频）	支撑域	运营辅助，提升留存	可用开源 CMS 改造

划分子域的权衡要点：

不要从技术模块出发。例如不要先想“需要一个 UserService”，而要想“会员管理”这个业务能力。
核心域通常只有 1-2 个。如果把所有子域都标成核心，等于没有重点。
通用域不要自己造轮子。支付、通知直接买，团队精力留给核心域。
子域边界可以随业务演化。MVP 阶段可以把“训练计划”放在“课程域”里，等业务复杂后再拆出来。

11.3 第二步：划分限界上下文

划分的核心问题是：同一个业务名词，在不同地方含义是否不同？生命周期是否独立？

以“课程”这个词为例：

上下文	“课程”在该上下文中的含义	关键概念
课程目录上下文	可售卖的课程 SKU：价格、有效期、适用人群、退费规则	CourseCatalog, PricePolicy
预约调度上下文	一次具体的上课时间：教练、学员、时段、状态	Appointment, TimeSlot
训练记录上下文	一次实际上课产生的记录：消耗课时、训练内容、教练反馈	TrainingRecord, ConsumedSession
营销上下文	参与促销的课程范围：满减、套餐、优惠券适用	PromotionRule, Bundle
财务上下文	课程订单的应收、实收、退款流水	CourseOrder, Refund

因为“课程”的含义和生命周期在每个上下文里都不同，所以应该拆成不同的限界上下文。FitCoach 最终划分如下：

课程目录上下文（Course Catalog Context）
预约调度上下文（Scheduling Context）
训练记录上下文（Training Record Context）
会员上下文（Member Context）
教练上下文（Coach Context）
支付上下文（Payment Context）
营销上下文（Marketing Context）
消息通知上下文（Notification Context）

关键判断：如果两个地方对同一个名词的定义和生命周期不同，就倾向于拆成不同上下文；如果概念高度一致且总是一起变化，可以合并。

11.4 第三步：推导微服务边界

默认规则是一个限界上下文对应一个微服务，但 FitCoach 还要考虑团队规模、数据一致性、发布频率、性能特征。

限界上下文	微服务决策	决策理由
课程目录	独立服务	变化频繁，运营经常调整 SKU 和价格
预约调度	独立服务	高并发读，学员大量刷可选时段，需单独伸缩
训练记录	独立服务	写多读少，数据量大，未来可能要独立归档
会员 + 教练档案	合并为“账户服务”	MVP 阶段都很薄，且登录后经常一起查询；内部用模块隔离
支付	独立服务	涉及资金安全、合规审计、对接第三方
营销	独立服务	活动频繁，不能影响核心预约链路
消息通知	独立服务	可被多个业务复用，适合独立演进

合并的例外处理：

会员和教练虽然业务概念不同，但 MVP 阶段数据模型简单，合并可以减少一次远程调用。
如果后续教练业务复杂化（排期、评级、分成、资质认证），再把教练上下文拆成独立服务。

一句话：微服务边界从限界上下文出发，再结合团队、性能、合规、数据一致性做微调。

11.5 第四步：选择上下文映射模式

不同上下文之间不是孤立的，需要显式定义它们如何协作。

graph LR
    A[预约上下文] -->|Customer-Supplier| B[课程目录上下文]
    C[训练记录上下文] -->|Customer-Supplier| A
    D[支付上下文] -->|OHS + PL| E[预约上下文]
    F[营销上下文] -->|Shared Kernel| A
    G[消息通知上下文] -->|Conformist| H[短信/推送第三方]
    I[账户服务] -->|OHS + PL| J[所有业务服务]
    K[训练记录上下文] -->|ACL| L[直播上课工具]

关系	模式	说明
预约 → 课程目录	客户-供应商	预约需要课程的名称、价格、时长；课程目录提供稳定查询接口
训练记录 → 预约	客户-供应商	训练记录基于已完成的预约生成
支付 → 各业务	开放主机服务 OHS	支付提供统一的收款、退款、对账 API
营销 → 预约	共享内核 Shared Kernel	促销分摊、优惠券核销规则需要双方共同维护
消息通知 → 第三方	遵奉者 Conformist	直接调用第三方 SDK，模型由第三方定义
训练记录 → 直播工具	防腐层 ACL	直播工具接口不稳定，通过 ACL 隔离，保护领域模型

11.6 第五步：充血模型 vs 贫血模型决策

DDD 并不要求全场充血。模型选择应该看该上下文的业务复杂度，而不是追求统一风格。

上下文	推荐模型	理由
预约调度	充血模型	状态机复杂：待预约 → 已预约 → 已签到 → 已完成 → 已取消；有取消规则、爽约规则
训练记录	充血模型	记录不可变，但课时消耗计算、教练评分聚合有业务规则
课程目录	贫血模型可接受	主要是 CRUD，业务规则少
账户服务	贫血模型	数据管理为主，验证规则简单
消息通知	贫血/过程式	基本是发送逻辑，无复杂领域规则
营销	充血模型	优惠计算、互斥规则、分摊逻辑复杂

预约上下文的充血模型示例：

public class Appointment {
    private AppointmentId id;
    private TimeSlot timeSlot;
    private MemberId memberId;
    private CoachId coachId;
    private AppointmentStatus status;
    private List<DomainEvent> domainEvents = new ArrayList<>();

    public void cancel(LocalDateTime now) {
        if (status != AppointmentStatus.BOOKED) {
            throw new DomainException("只能取消已预约的课程");
        }
        if (timeSlot.start().minusHours(24).isBefore(now)) {
            throw new DomainException("开课 24 小时内不可取消");
        }
        this.status = AppointmentStatus.CANCELLED;
        domainEvents.add(new AppointmentCancelled(id, now));
    }

    public void checkIn(LocalDateTime now) {
        if (status != AppointmentStatus.BOOKED) {
            throw new DomainException("未预约不能签到");
        }
        this.status = AppointmentStatus.COMPLETED;
        domainEvents.add(new AppointmentCheckedIn(id, memberId, coachId, now));
    }
}

决策口诀：

状态机复杂、不变量多、业务规则变化快 → 充血模型
主要是增删改查、数据为主、规则简单 → 贫血模型即可
不确定时，先写贫血，等规则复杂了再重构为充血

11.7 第六步：DDD 是否可以裁剪？

可以，而且应该根据项目情况裁剪。 DDD 不是全有或全无的框架。

场景 1：只用战略设计，战术设计从简

适合情况：业务复杂但技术栈简单、团队经验不足、MVP 阶段要快速上线。
FitCoach 初期做法：先画好限界上下文和微服务边界，服务内部用简单 CRUD + Service 实现。
价值：至少解决了“边界混乱、术语不一致、重复造轮子”的问题。

场景 2：只用战术设计，在已有边界内建模

适合情况：系统边界已经清楚，但某个模块内部逻辑混乱（如遗留系统重构）。
FitCoach 示例：课程目录已经稳定，但预约状态机满是 if/else，可以只对“预约上下文”做充血模型重构。
风险：如果战略边界本身不清晰，战术设计会变成“在错误的地方做正确的事”。

场景 3：战略 + 战术都用，但不用高级模式

这是最常见的落地方式。
FitCoach 可以用：限界上下文 + 充血模型 + 领域事件 + 分层架构。
可以先不用：事件溯源、CQRS、六边形架构的严格形式。

裁剪原则

复杂的地方用 DDD，简单的地方不要硬套。
先战略后战术，边界不清不要深入建模型。
一个项目可以不同上下文用不同成熟度：核心域充血 + 贫血，通用域直接用 SDK。
不要为了 DDD 而 DDD，目标是降低业务复杂度，不是写出“DDD 标准代码”。

11.8 落地时间线建议

阶段	目标	关键产出
Week 1-2	事件风暴 + 统一语言	子域图、限界上下文图、术语表
Week 3	微服务边界与映射模式	服务拆分方案、接口契约初稿
Week 4-6	核心域战术设计	聚合、实体、值对象、领域事件、测试
Week 7-8	基础设施 + 集成测试	数据库、消息队列、CI/CD 流水线
持续	演进	根据业务变化调整边界和模型

新手常犯的错误：一上来就在所有服务里写聚合根、值对象、领域事件。正确做法是先画地图，再对核心域精雕细琢，其他域能跑通即可。

十二、一句话总结

DDD = 用“统一语言”沟通业务，用“限界上下文”划分边界并推导微服务边界，用“聚合/实体/值对象”封装领域知识，用“领域事件”连接上下文，让软件结构真正反映业务结构。

把 soulnew/ddd-demo 的 Demo 跑一遍，再画一张你自己业务的战略地图，并尝试标出可能的微服务边界，你就已经比 80% 自称做 DDD 的人更接近它的本质了。

参考

Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software
Vaughn Vernon. Implementing Domain-Driven Design
Vaughn Vernon. Domain-Driven Design Distilled

设计模式全景图：六大原则、23 种 GoF 模式与 J2EE 模式

Tue, 28 May 2019 14:00:00 +0800

设计模式全景图：六大原则、23 种 GoF 模式与 J2EE 模式

设计模式是面向对象设计中反复出现问题的可复用解决方案。掌握它们能够帮助我们写出更易扩展、更易维护、更清晰的代码。本文从六大设计原则出发，完整梳理 GoF 23 种设计模式以及 8 种 J2EE 模式，并配合类图、意图说明和 JDK/Spring 中的典型应用，帮助建立系统性的知识地图。

一、设计模式的六大原则

1. 开闭原则（Open Close Principle）

对扩展开放，对修改关闭。

当程序需要新增功能时，应通过增加新代码实现，而不是修改已有代码。核心手段是抽象化：使用接口和抽象类。

graph LR
    A[业务调用方] --> B[抽象接口]
    B --> C[旧实现]
    B --> D[新实现]
    style D fill:#e1f5e1

2. 里氏代换原则（Liskov Substitution Principle）

任何基类可以出现的地方，子类一定可以出现。子类替换基类后，程序功能不应受影响。

classDiagram
    class Animal { +eat() }
    class Dog { +eat() }
    class Cat { +eat() }
    Animal <|-- Dog
    Animal <|-- Cat

3. 依赖倒转原则（Dependence Inversion Principle）

高层模块和低层模块都应依赖抽象；要针对接口编程，而不是针对实现编程。

4. 接口隔离原则（Interface Segregation Principle）

使用多个职责单一的接口，优于使用一个庞大臃肿的接口，降低类之间的耦合。

graph TD
    A[大接口] -->|拆分为| B[接口A]
    A -->|拆分为| C[接口B]
    A -->|拆分为| D[接口C]
    B --> E[实现类1]
    C --> F[实现类2]
    D --> G[实现类3]

5. 迪米特法则 / 最少知道原则（Demeter Principle）

一个实体应尽量少地与其他实体发生直接交互，降低模块耦合，提高独立性。

6. 合成复用原则（Composite Reuse Principle）

优先使用组合/聚合来复用功能，而不是继承。组合更灵活，耦合更低。

classDiagram
    class Car { -Engine engine; +run() }
    class Engine { +start() }
    Car *-- Engine : 组合

二、设计模式分类概览

设计模式通常分为三大类：创建型、结构型、行为型。J2EE 模式则专注于企业应用和表示层。

mindmap
  root((设计模式))
    创建型模式 5种
      工厂模式
      抽象工厂模式
      单例模式
      建造者模式
      原型模式
    结构型模式 8种
      适配器模式
      桥接模式
      过滤器/标准模式
      组合模式
      装饰器模式
      外观模式
      享元模式
      代理模式
    行为型模式 13种 
      责任链模式
      命令模式
      解释器模式
      迭代器模式
      中介者模式
      备忘录模式
      观察者模式
      状态模式
      空对象模式
      策略模式
      模板模式
      访问者模式
    J2EE模式 8种 
      MVC模式
      业务代表模式
      组合实体模式
      数据访问对象模式
      前端控制器模式
      拦截过滤器模式
      服务定位器模式
      传输对象模式

三、创建型模式（Creational Patterns）

创建型模式关注对象的创建过程，隐藏创建逻辑，使程序在判断需要创建哪些对象时更灵活。

1. 工厂模式（Factory Pattern）

定义一个创建对象的接口，让子类决定实例化哪一个类。工厂方法使类的实例化延迟到子类。

classDiagram
    class Product { <<interface>> +use() }
    class ConcreteProductA { +use() }
    class ConcreteProductB { +use() }
    class Creator { +factoryMethod() Product }
    class ConcreteCreatorA { +factoryMethod() Product }
    class ConcreteCreatorB { +factoryMethod() Product }
    Product <|.. ConcreteProductA
    Product <|.. ConcreteProductB
    Creator <|-- ConcreteCreatorA
    Creator <|-- ConcreteCreatorB
    Creator ..> Product
    ConcreteCreatorA ..> ConcreteProductA
    ConcreteCreatorB ..> ConcreteProductB

JDK 应用： java.text.DateFormat.getDateInstance()、KeyGenerator.getInstance()。

2. 抽象工厂模式（Abstract Factory Pattern）

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

classDiagram
    class AbstractFactory { <<interface>> +createProductA() +createProductB() }
    class ConcreteFactory1 { +createProductA() +createProductB() }
    class ConcreteFactory2 { +createProductA() +createProductB() }
    class AbstractProductA
    class AbstractProductB
    AbstractFactory <|.. ConcreteFactory1
    AbstractFactory <|.. ConcreteFactory2
    ConcreteFactory1 ..> AbstractProductA
    ConcreteFactory1 ..> AbstractProductB
    ConcreteFactory2 ..> AbstractProductA
    ConcreteFactory2 ..> AbstractProductB

3. 单例模式（Singleton Pattern）

确保一个类只有一个实例，并提供一个全局访问点。

classDiagram
    class Singleton {
        -static Singleton instance
        -Singleton()
        +static getInstance() Singleton
    }

JDK 应用： Runtime.getRuntime()。Spring 应用： 默认 Bean 作用域为单例。

4. 建造者模式（Builder Pattern）

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

classDiagram
    class Product { +partA +partB +partC }
    class Builder { <<interface>> +buildPartA() +buildPartB() +getResult() }
    class ConcreteBuilder { +buildPartA() +buildPartB() +getResult() }
    class Director { +construct(builder) }
    Builder <|.. ConcreteBuilder
    ConcreteBuilder ..> Product
    Director ..> Builder

5. 原型模式（Prototype Pattern）

通过复制现有对象来创建新对象，而不是新建实例。适用于创建成本较高的对象。

classDiagram
    class Prototype { <<interface>> +clone() }
    class ConcretePrototype { +clone() }
    Prototype <|.. ConcretePrototype

JDK 应用： Object.clone()、Cloneable 接口。

四、结构型模式（Structural Patterns）

结构型模式关注对象之间的组合和关系，解决如何构建灵活且可复用的类和对象结构。

1. 适配器模式（Adapter Pattern）

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以协同工作。

classDiagram
    class Target { <<interface>> +request() }
    class Adapter { +request() }
    class Adaptee { +specificRequest() }
    Target <|.. Adapter
    Adapter --> Adaptee

JDK 应用： Arrays.asList()、InputStreamReader。

2. 桥接模式（Bridge Pattern）

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

classDiagram
    class Abstraction { -Implementor impl +operation() }
    class RefinedAbstraction { +operation() }
    class Implementor { <<interface>> +operationImpl() }
    class ConcreteImplementorA { +operationImpl() }
    class ConcreteImplementorB { +operationImpl() }
    Abstraction <|-- RefinedAbstraction
    Abstraction o-- Implementor
    Implementor <|.. ConcreteImplementorA
    Implementor <|.. ConcreteImplementorB

3. 过滤器模式 / 标准模式（Filter / Criteria Pattern）

使用不同的标准来过滤一组对象，并通过逻辑运算以解耦的方式把它们连接起来。常用于集合筛选。

classDiagram
    class Criteria { <<interface>> +meetCriteria(list) }
    class CriteriaMale { +meetCriteria(list) }
    class CriteriaFemale { +meetCriteria(list) }
    class AndCriteria { +meetCriteria(list) }
    class OrCriteria { +meetCriteria(list) }
    Criteria <|.. CriteriaMale
    Criteria <|.. CriteriaFemale
    Criteria <|.. AndCriteria
    Criteria <|.. OrCriteria
    AndCriteria --> Criteria
    OrCriteria --> Criteria

4. 组合模式（Composite Pattern）

将对象组合成树形结构以表示"部分-整体"的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

classDiagram
    class Component { +operation() }
    class Leaf { +operation() }
    class Composite { -children +add() +remove() +operation() }
    Component <|-- Leaf
    Component <|-- Composite
    Composite o-- Component

JDK 应用： java.awt.Container 与 Component。

5. 装饰器模式（Decorator Pattern）

动态地给一个对象添加一些额外的职责，比生成子类更灵活。

classDiagram
    class Component { <<interface>> +operation() }
    class ConcreteComponent { +operation() }
    class Decorator { -Component component +operation() }
    class ConcreteDecoratorA { +operation() }
    class ConcreteDecoratorB { +operation() }
    Component <|.. ConcreteComponent
    Component <|.. Decorator
    Decorator <|-- ConcreteDecoratorA
    Decorator <|-- ConcreteDecoratorB
    Decorator o-- Component

JDK 应用： Java IO 流 BufferedInputStream、DataInputStream、ZipOutputStream。

6. 外观模式（Facade Pattern）

为子系统中的一组接口提供一个一致的入口，定义了一个高层接口，使子系统更容易使用。

classDiagram
    class Facade { +simplifiedOperation() }
    class SubSystemA { +operationA() }
    class SubSystemB { +operationB() }
    class SubSystemC { +operationC() }
    Facade --> SubSystemA
    Facade --> SubSystemB
    Facade --> SubSystemC

7. 享元模式（Flyweight Pattern）

运用共享技术有效地支持大量细粒度对象，减少内存占用。

classDiagram
    class FlyweightFactory { -pool +getFlyweight(key) }
    class Flyweight { <<interface>> +operation() }
    class ConcreteFlyweight { +operation() }
    FlyweightFactory o-- Flyweight
    Flyweight <|.. ConcreteFlyweight

JDK 应用： Integer.valueOf() 缓存（-128-127）、String 常量池。

8. 代理模式（Proxy Pattern）

为其他对象提供一种代理以控制对这个对象的访问。

classDiagram
    class Subject { <<interface>> +request() }
    class RealSubject { +request() }
    class Proxy { -RealSubject real +request() }
    Subject <|.. RealSubject
    Subject <|.. Proxy
    Proxy --> RealSubject

JDK 应用： JDK 动态代理 Proxy.newProxyInstance()。Spring 应用： AOP 使用 JDK 动态代理和 CGLIB。

五、行为型模式（Behavioral Patterns）

行为型模式关注对象之间的通信和交互，解决对象之间的责任分配和算法封装。

1. 责任链模式（Chain of Responsibility Pattern）

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求。

classDiagram
    class Handler { <<interface>> +setNext(handler) +handle(request) }
    class ConcreteHandlerA { +handle(request) }
    class ConcreteHandlerB { +handle(request) }
    Handler <|.. ConcreteHandlerA
    Handler <|.. ConcreteHandlerB
    Handler --> Handler : next

2. 命令模式（Command Pattern）

将请求封装为对象，从而可以用不同的请求、队列或日志来参数化其他对象，同时支持可撤销操作。

classDiagram
    class Command { <<interface>> +execute() }
    class ConcreteCommand { -receiver +execute() }
    class Invoker { -command +setCommand() +invoke() }
    class Receiver { +action() }
    Command <|.. ConcreteCommand
    Invoker --> Command
    ConcreteCommand --> Receiver

3. 解释器模式（Interpreter Pattern）

给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

classDiagram
    class AbstractExpression { +interpret(context) }
    class TerminalExpression { +interpret(context) }
    class NonterminalExpression { +interpret(context) }
    AbstractExpression <|-- TerminalExpression
    AbstractExpression <|-- NonterminalExpression
    NonterminalExpression o-- AbstractExpression

JDK 应用： Java 正则表达式 Pattern 与 Matcher。

4. 迭代器模式（Iterator Pattern）

提供一种方法顺序访问一个聚合对象中的各个元素，而又无需暴露该对象的内部表示。

classDiagram
    class Iterator { <<interface>> +hasNext() +next() }
    class ConcreteIterator { +hasNext() +next() }
    class Aggregate { <<interface>> +createIterator() }
    class ConcreteAggregate { +createIterator() }
    Iterator <|.. ConcreteIterator
    Aggregate <|.. ConcreteAggregate
    ConcreteAggregate ..> ConcreteIterator

JDK 应用： java.util.Iterator、java.util.Enumeration。

5. 中介者模式（Mediator Pattern）

用一个中介对象来封装一系列对象交互，使对象不需要显式地相互引用，从而使其耦合松散。

classDiagram
    class Mediator { <<interface>> +send(message, colleague) }
    class ConcreteMediator { +send(message, colleague) }
    class Colleague { -Mediator mediator }
    class ConcreteColleagueA
    class ConcreteColleagueB
    Mediator <|.. ConcreteMediator
    Colleague <|-- ConcreteColleagueA
    Colleague <|-- ConcreteColleagueB
    Colleague --> Mediator
    ConcreteMediator --> ConcreteColleagueA
    ConcreteMediator --> ConcreteColleagueB

6. 备忘录模式（Memento Pattern）

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后恢复。

classDiagram
    class Originator { +createMemento() +restore(memento) }
    class Memento { -state }
    class Caretaker { -mementos }
    Originator ..> Memento
    Caretaker o-- Memento

7. 观察者模式（Observer Pattern）

定义对象间的一对多依赖关系，当一个对象状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

classDiagram
    class Subject { <<interface>> +registerObserver() +removeObserver() +notifyObservers() }
    class ConcreteSubject { -state +notifyObservers() }
    class Observer { <<interface>> +update() }
    class ConcreteObserverA { +update() }
    class ConcreteObserverB { +update() }
    Subject <|.. ConcreteSubject
    Observer <|.. ConcreteObserverA
    Observer <|.. ConcreteObserverB
    ConcreteSubject --> Observer

JDK 应用： java.util.Observer（已弃用）和 Observable。Spring 应用： Spring 事件驱动模型 ApplicationEvent、ApplicationListener。

8. 状态模式（State Pattern）

允许对象在其内部状态改变时改变它的行为，对象看起来好像修改了它的类。

classDiagram
    class Context { -State state +request() }
    class State { <<interface>> +handle() }
    class ConcreteStateA { +handle() }
    class ConcreteStateB { +handle() }
    Context o-- State
    State <|.. ConcreteStateA
    State <|.. ConcreteStateB

9. 空对象模式（Null Object Pattern）

用一个空对象取代 null 检查，提供默认的"什么也不做"的行为，避免空指针异常。

classDiagram
    class Animal { <<interface>> +makeSound() }
    class Dog { +makeSound() }
    class NullAnimal { +makeSound() }
    Animal <|.. Dog
    Animal <|.. NullAnimal

10. 策略模式（Strategy Pattern）

定义一系列算法，把它们一个个封装起来，并且使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户。

classDiagram
    class Strategy { <<interface>> +execute() }
    class ConcreteStrategyA { +execute() }
    class ConcreteStrategyB { +execute() }
    class Context { -Strategy strategy +setStrategy() +executeStrategy() }
    Strategy <|.. ConcreteStrategyA
    Strategy <|.. ConcreteStrategyB
    Context o-- Strategy

JDK 应用： Comparator 接口与 Collections.sort()。

11. 模板模式（Template Pattern）

定义一个操作中的算法骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变算法结构即可重定义该算法的某些特定步骤。

classDiagram
    class AbstractClass { +templateMethod() +primitiveOperation() }
    class ConcreteClass { +primitiveOperation() }
    AbstractClass <|-- ConcreteClass

JDK 应用： Arrays.sort() 配合 Comparable。Spring 应用： RestTemplate、JmsTemplate、JpaTemplate。

12. 访问者模式（Visitor Pattern）

表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。

classDiagram
    class Element { <<interface>> +accept(visitor) }
    class ConcreteElementA { +accept(visitor) }
    class ConcreteElementB { +accept(visitor) }
    class Visitor { <<interface>> +visitA() +visitB() }
    class ConcreteVisitor { +visitA() +visitB() }
    Element <|.. ConcreteElementA
    Element <|.. ConcreteElementB
    Visitor <|.. ConcreteVisitor
    ConcreteElementA ..> Visitor
    ConcreteElementB ..> Visitor

六、J2EE 模式

J2EE 模式专注于企业应用，尤其是表示层和业务层的架构设计。这些模式由 Sun Java Center 鉴定。

1. MVC 模式（MVC Pattern）

将应用程序分为 Model（模型）、View（视图）、Controller（控制器）三层，实现关注点分离。

graph LR
    V[View] --> C[Controller]
    C --> M[Model]
    M --> V

Spring 应用： Spring MVC 是典型实现。

2. 业务代表模式（Business Delegate Pattern）

为表示层提供对业务服务的访问抽象，减少表示层与业务层之间的耦合。

graph LR
    A[Client/Controller] --> B[Business Delegate]
    B --> C[Business Service]
    C --> D[DAO/数据层]

3. 组合实体模式（Composite Entity Pattern）

将一组相关的持久化对象组合成一个粗粒度实体，减少网络调用次数，提高性能。

classDiagram
    class CompositeEntity { -DependentObjectA a -DependentObjectB b +getData() }
    class DependentObjectA
    class DependentObjectB
    CompositeEntity *-- DependentObjectA
    CompositeEntity *-- DependentObjectB

4. 数据访问对象模式（Data Access Object Pattern）

将底层数据访问逻辑与高层业务逻辑分离，提供一个统一的接口访问数据库。

graph LR
    A[Business Object] --> B[DAO Interface]
    B --> C[DAO Implementation]
    C --> D[Data Source/Database]

Spring 应用： Spring Data JPA、MyBatis Mapper 都是 DAO 模式的具体实现。

5. 前端控制器模式（Front Controller Pattern）

提供一个集中的入口点来处理所有请求，通常负责认证、日志、路由等横切关注点。

graph LR
    A[所有请求] --> B[Front Controller]
    B --> C[Dispatcher]
    C --> D[具体 Handler]

Spring 应用： DispatcherServlet 是前端控制器模式的实现。

6. 拦截过滤器模式（Intercepting Filter Pattern）

在请求到达目标处理器之前，通过一系列过滤器链对请求进行预处理（如编码、认证、日志）。

graph LR
    A[Request] --> F1[Filter 1]
    F1 --> F2[Filter 2]
    F2 --> F3[Filter N]
    F3 --> T[Target]
    T --> F3
    F3 --> F2
    F2 --> F1
    F1 --> R[Response]

Spring 应用： Spring 的 HandlerInterceptor、Servlet Filter。

7. 服务定位器模式（Service Locator Pattern）

提供一个中心化的注册表，用于获取服务实例，减少服务依赖的直接查找。

classDiagram
    class ServiceLocator { +getService(name) }
    class Cache { -services }
    class InitialContext { +lookup(name) }
    class Service { <<interface>> +execute() }
    ServiceLocator --> Cache
    ServiceLocator --> InitialContext
    ServiceLocator ..> Service

8. 传输对象模式（Transfer Object Pattern）

通过简单的 POJO 对象在不同层之间传输数据，减少远程调用的网络开销，也称为 DTO（Data Transfer Object）。

classDiagram
    class UserDTO { -id -name -email +getters/setters }
    class UserService { +getUserDTO(id) }
    class UserController { +showUser(dto) }
    UserService ..> UserDTO
    UserController ..> UserDTO

七、JDK、Java IO 与 Spring 中的模式速查

模式	JDK 示例	Spring 示例
工厂模式	`DateFormat.getDateInstance()`、`KeyGenerator.getInstance()`	`BeanFactory`
单例模式	`Runtime.getRuntime()`	默认 Bean 作用域
原型模式	`Object.clone()`、`Cloneable`	`@Scope("prototype")`
适配器模式	`Arrays.asList()`、`InputStreamReader`	MVC 的 Controller 适配器
装饰器模式	`BufferedInputStream`、`ZipOutputStream`	-
代理模式	JDK 动态代理	AOP
组合模式	`java.awt.Container` / `Component`	-
享元模式	`Integer.valueOf()`、`String` 常量池	-
模板方法模式	`Arrays.sort()` + `Comparable`	`RestTemplate`、`JpaTemplate`
策略模式	`Comparator`、`Collections.sort()`	`ResourceLoader` 策略
观察者模式	`Observer` / `Observable`	Spring 事件驱动模型
解释器模式	`Pattern` / `Matcher`	SpEL 表达式
责任链模式	Servlet Filter Chain	`HandlerInterceptor` 链
MVC 模式	-	Spring MVC
DAO 模式	JDBC Template	Spring Data JPA / MyBatis
前端控制器	-	`DispatcherServlet`

Java IO 中使用的模式

Java IO 同时使用了适配器模式和装饰器模式：

适配器模式： InputStreamReader 将 InputStream 字节流适配为 Reader 字符流。
装饰器模式： BufferedInputStream、DataInputStream、ZipOutputStream 等通过包装 InputStream 动态增强功能。

// 装饰器模式：逐层包装
InputStream fis = new FileInputStream("file.txt");
InputStream bis = new BufferedInputStream(fis);     // 增加缓冲
DataInputStream dis = new DataInputStream(bis);      // 增加基本类型读取

// 适配器模式：字节流转字符流
Reader reader = new InputStreamReader(fis, StandardCharsets.UTF_8);

八、如何选择设计模式

设计模式不是越复杂越好。选择时可以从以下角度思考：

问题类型：是对象创建、结构组织，还是行为交互？
变化方向：系统中哪些部分经常变化？把变化的部分封装起来。
开闭原则：新增功能时是否能不修改已有代码？
复杂度收益：不要为了用模式而增加不必要的抽象。

一张简化的决策地图：

flowchart TD
    A[遇到设计问题] --> B{对象创建复杂?}
    B -->|是| C[创建型模式]
    B -->|否| D{对象结构复杂?}
    D -->|是| E[结构型模式]
    D -->|否| F{对象交互复杂?}
    F -->|是| G[行为型模式]
    F -->|否| H[保持简单，遵循原则]

总结

设计模式是前人总结的设计经验，核心目标是让软件更易扩展、更易维护、更易理解。掌握它们的关键不是背诵每个类图，而是：

理解六大原则，它们是选择模式的判断依据；
熟悉 23 种 GoF 模式和 J2EE 模式的适用场景；
多读优秀源码（JDK、Spring），在真实代码中感受模式的应用；
避免过度设计，合适才是最好的。

从 BeanFactory 到 DispatcherServlet，从 Java IO 的装饰器到 Spring AOP 的代理，设计模式无处不在。理解这些模式，能帮助我们在面对复杂系统时做出更清晰的结构选择。

参考：

菜鸟教程 - 设计模式

dailyprogrammer - JDK 类库常用的设计模式

Design Patterns: Elements of Reusable Object-Oriented Software (GoF)

PMP 入门与实战：从项目经理角色认知到沟通方法

Wed, 09 Aug 2017 10:00:00 +0800

PMP 入门与实战：从项目经理角色认知到沟通方法

我在华为电软核担任项目经理，这是我给新人培训材料的总结。项目管理不是把活派出去就完事，而是在有限的时间、预算、资源约束下，带领团队把事儿做成。这篇文章结合 PMP 体系与一线交付经验，帮你用最快的速度建立 PM 的角色认知和实战感。

一、PM 不是高级打杂，而是项目的总导演

很多新人第一次做 PM 时会有错觉：PM 就是催进度、拉会议、写周报的“高级打杂”。但真正的 PM 是项目的总导演——你对最终交付结果负责，而不是只负责传话。

1.1 项目经理的四个角色

结合 PM 角色认知模型，项目经理要同时承担四个责任：

flowchart TB
    PM([项目经理 PM])
    D[项目按要求交付责任者]
    T[团队建设责任者]
    O[组织能力建设责任者]
    B[项目经营责任者]

    PM --> D
    PM --> T
    PM --> O
    PM --> B

    D --> D1[启动 / 计划 / 执行 / 监控 / 验收 / 关闭]
    T --> T1[核心团队运作 / 人员能力提升 / 组织氛围]
    O --> O1[流程方法 / 工具建设 / 过程资产积累]
    B --> B1[收入管理 / 成本控制 / 业务拓展]

简单记忆：

角色	关键词	日常表现
交付责任者	按期、按质、按预算	盯进度、管风险、控变更、搞验收
团队建设者	人心、能力、氛围	布阵点兵、辅导下属、解决冲突
组织能力建设者	流程、方法、资产	沉淀模板、优化流程、分享经验
经营责任者	赚钱、省钱、控成本	成本评估、收入确认、变更报价

1.2 从个人贡献者到团队绩效达成者

PM 是一次“转身”：以前你关注“我干得怎么样”，现在你要关注“我们团队干得怎么样”。

flowchart LR
    A[独立贡献者<br/>个人绩效] -->|转身| B[项目经理<br/>团队绩效]
    B --> C[关注事]
    B --> D[关注人]
    C --> C1[计划 / 进度 / 质量 / 风险]
    D --> D1[沟通 / 激励 / 培养 / 冲突]

新人自检三问：

我是谁？（我在这个项目里的核心职责是什么）
我的优势劣势？（我擅长技术、沟通还是流程）
我的工作方式？（我习惯先发制人还是被动响应）

二、PMP 核心原理：五大过程组

PMP 把项目管理抽象成 49 个过程，归入 5 大过程组 和 10 大知识领域。新人不用背 49 个过程，先理解 5 大过程组的逻辑。

2.1 五大过程组循环

flowchart LR
    A[启动<br/>Initiating] --> B[规划<br/>Planning]
    B --> C[执行<br/>Executing]
    C --> D[监控<br/>Monitoring & Controlling]
    D --> E[收尾<br/>Closing]
    D --> B
    D --> C
    E --> A

    style A fill:#e0f2fe
    style B fill:#dcfce7
    style C fill:#fef9c3
    style D fill:#fee2e2
    style E fill:#f3e8ff

过程组	核心问题	关键输出
启动	为什么要做？值不值得做？	项目章程、干系人登记册
规划	怎么做？谁来做？什么时候做完？	项目管理计划、WBS、进度基准、成本基准
执行	按计划推进，协调资源与人	可交付成果、变更请求
监控	偏差多少？要不要纠偏？	工作绩效报告、变更请求、纠正措施
收尾	做完了吗？经验留下了吗？	验收报告、经验教训、项目关闭

注意：五大过程组不是严格的“阶段”，它们会重叠、反复、交叉。比如监控贯穿始终，规划也可能在执行中重新发生。

2.2 十大知识领域一句话版

flowchart TB
    subgraph KA[十大知识领域]
        direction LR
        A1[整合管理] --> A2[范围管理]
        A2 --> A3[进度管理]
        A3 --> A4[成本管理]
        A4 --> A5[质量管理]
        A5 --> A6[资源管理]
        A6 --> A7[沟通管理]
        A7 --> A8[风险管理]
        A8 --> A9[采购管理]
        A9 --> A10[干系人管理]
    end

知识领域	核心问题	新人重点
整合管理	怎么把零散的事串成整体？	写计划、做变更、开阶段评审
范围管理	到底做什么？不做什么？	WBS、需求澄清、范围变更控制
进度管理	什么时候做完？	里程碑、甘特图、关键路径
成本管理	要花多少钱？能不能省？	估算、预算、挣值分析
质量管理	做成什么样才算好？	验收标准、测试计划、质量回溯
资源管理	需要谁？怎么激励？	团队组建、责任分配矩阵 RAM
沟通管理	跟谁说什么？怎么说？	沟通计划、例会、周报、话术
风险管理	什么可能搞砸？怎么应对？	风险登记册、应急预案
采购管理	哪些东西要外购？	SOW、合同、供应商管理
干系人管理	谁在意这个项目？怎么管理期望？	干系人登记册、参与策略

三、项目铁三角与新六边形

3.1 传统铁三角

flowchart LR
    A[范围 Scope] --- B[进度 Schedule]
    B --- C[成本 Cost]
    C --- A

3.2 PMP 更完整的六边形制约

现代项目管理认为，项目受多个因素共同制约：

flowchart TB
    Q[质量 Quality]
    S[范围 Scope]
    C[成本 Cost]
    T[进度 Time/Schedule]
    R[风险 Risk]
    RE[资源 Resources]

    Q --- S
    S --- C
    C --- T
    T --- R
    R --- RE
    RE --- Q

新人最常踩的坑：客户说“加个小功能，不影响进度和成本”。你要意识到：范围变了，进度、成本、质量、风险几乎都会变，只是影响大小不同。PM 的职责是把这些影响量化出来，让决策者做知情选择。

四、项目规划：把大目标拆成可执行的小任务

规划阶段是 PM 最需要下功夫的阶段。规划不好，执行再努力也白搭。

4.1 计划分级：不同人看不同粒度

级别	名称	用途	读者
0 级	里程碑计划	只显示关键节点	公司管理层、项目集经理
1 级	职能领域计划	各职能主要工作	项目经理、核心团队
2 级	专项详细计划	开发/测试/采购等展开	模块负责人
3 级	个人执行计划	任务到天/人	项目成员

4.2 WBS：工作分解结构

WBS 是项目规划的骨架。核心原则：

100% 原则：所有项目工作都要被分解，不能遗漏。
4-6 层原则：一般 4 层左右，别超过 6 层。
80 工时原则：最底层任务一般不超过 80 小时（约 2 周）。
滚动式规划：近期详细，远期粗略。
干系人参与：让相关人一起拆，不要 PM 一个人拍脑袋。

flowchart TD
    A[OTT 平台交付项目] --> B[需求与设计]
    A --> C[平台部署]
    A --> D[终端开发]
    A --> E[内容对接]
    A --> F[测试验收]
    A --> G[项目关闭]

    B --> B1[需求澄清会]
    B --> B2[方案设计]
    B --> B3[SOW 确认]

    C --> C1[云资源开通]
    C --> C2[流媒体部署]
    C --> C3[CDN 配置]

    D --> D1[Android STB]
    D --> D2[iOS Mobile]
    D --> D3[SmartTV]
    D --> D4[PC Web]

    E --> E1[直播源接入]
    E --> E2[VOD 内容上传]
    E --> E3[DRM 对接]

    F --> F1[E2E 测试]
    F --> F2[客户验收]
    F --> F3[问题整改]

    G --> G1[交付件归档]
    G --> G2[转维培训]
    G --> G3[项目总结]

4.3 甘特图、里程碑、燃尽图

甘特图：横轴时间，纵轴任务，直观显示“谁什么时候做什么”。
里程碑：项目中的关键节点，通常零工期，用来标志阶段完成。
燃尽图：敏捷项目常用，显示剩余工作量随时间下降的趋势。

gantt
    title 示例：OTT 项目关键里程碑
    dateFormat  YYYY-MM-DD
    section 启动与规划
    项目启动会           :a1, 2015-08-01, 7d
    SOW 确认             :milestone, after a1, 0d
    详细计划基线         :milestone, 2015-08-15, 0d
    section 执行
    平台部署             :2015-08-16, 14d
    终端开发             :2015-08-20, 20d
    内容对接             :2015-09-01, 10d
    section 验收
    E2E 测试             :2015-09-11, 10d
    客户验收             :milestone, 2015-09-25, 0d
    项目关闭             :2015-09-26, 5d

五、项目执行与监控：PDCA 循环

执行与监控不是“盯人”，而是计划 → 实施 → 反馈 → 调整的循环。

flowchart TD
    P[Plan 计划] --> D[Do 执行]
    D --> C[Check 检查]
    C --> A[Act 调整]
    A --> P

    P -.->|基线| M[范围/进度/成本基准]
    C -.->|度量| D1[进度偏差<br/>成本偏差<br/>质量指标]
    A -.->|措施| D2[纠正 / 预防 / 缺陷补救]

监控阶段 PM 要回答的三个问题：

我们现在在哪？（实际进度、成本、质量）
我们离计划多远？（偏差）
我们要怎么做？（纠正措施、变更、上报）

六、沟通管理：PM 70% 时间都在沟通

PMP 认为沟通管理是项目成败的关键。PM 不是传声筒，而是信息的过滤器、翻译器和加速器。

6.1 沟通管理四步法

flowchart LR
    A[识别干系人] --> B[制定沟通计划]
    B --> C[执行沟通]
    C --> D[问题闭环]
    D --> A

6.2 干系人识别与分类

干系人就是对项目有影响或被项目影响的人。常见分类：

flowchart TB
    subgraph S[干系人四象限]
        direction LR
        A[高权力<br/>高利益] --- B[高权力<br/>低利益]
        C[低权力<br/>高利益] --- D[低权力<br/>低利益]
    end

    A --> A1[重点管理<br/>客户老板 / 项目发起人]
    B --> B1[令其满意<br/>职能部门领导]
    C --> C1[随时告知<br/>终端用户 / 运营人员]
    D --> D1[花最小精力监督<br/>外围支持人员]

6.3 沟通方式选择

场景	推荐方式	原因
复杂问题、有冲突	面对面 / 视频会议	能看到表情、即时反馈
需要留痕、正式确认	邮件 / 会议纪要	可追溯、可签字
日常进度同步	即时消息 / 日报	快速、轻量
跨部门协调	项目例会 / RACI 表	明确责任、统一节奏

6.4 高频沟通话术模板

场景 1：需求不明确，需要客户确认

“王总，关于 XX 功能，目前我们理解有两种实现方式：方案 A 是……，优点是……，缺点是……；方案 B 是……，优点是……，缺点是……。从项目范围和时间来看，我建议采用方案 A，您看是否可以确认？如果选 B，可能需要增加 3 天并调整后续测试计划。”

要点：给选项、讲影响、让客户做选择题而不是开放题。

场景 2：进度Delay，需要同步客户

“李经理，想和您同步一个情况：受第三方接口延迟影响，模块 X 预计比原计划晚 2 天。我们已经采取了以下措施：1. 协调对方优先级；2. 并行启动模块 Y 测试；3. 准备临时方案。目前整体里程碑仍可控，我们会每天同步进展。这是详细的影响评估，您看是否需要召开专项会议？”

要点：先说事实、再说影响、最后给措施和选项。

场景 3：客户提出范围变更

“张总，这个需求我们收到了。我先记录下来，明天下午 5 点前给您一份变更影响评估，包括：对进度、成本、质量、风险的影响，以及推荐方案。评估完成后我们再一起决策是否纳入本期交付。”

要点：不直接拒绝也不直接答应，用“评估 → 决策 → 实施”的流程争取时间。

场景 4：团队内部冲突

“你们两边的顾虑我都理解了：开发担心改动引发回归，测试希望尽早覆盖边界。我们的共同目标是按期高质量交付。这样，我们先用 15 分钟把边界场景列出来，评估改动范围，如果可控就本周内完成；如果范围大，就走变更流程。现在我们一起写一下场景清单。”

要点：点出共同目标、把冲突转化为任务、给明确截止时间。

场景 5：推动不愿配合的职能部门

“刘经理，这个任务在咱们项目计划里是模块 X 的前置依赖，目前距离截止时间还有 3 天。如果这边不能按期提供，会导致下游 5 个人停工，整体里程碑风险会上升到高。您看能否协调资源优先处理？如果需要我向上汇报协调，我也可以同步项目发起人。”

要点：讲清楚依赖关系、量化影响、给对方台阶也保留升级路径。

七、变更管理：拥抱变化，拒绝侥幸

变更是项目常态，但 PM 不能当“传话筒”，必须建立变更控制机制。

7.1 变更管理五步流程

flowchart TD
    A[变更识别] --> B[变更澄清]
    B --> C[变更分析]
    C --> D[变更决策]
    D --> E[变更实施与跟踪]
    E --> F[基线更新]

    A -->|任何人提出| A1[记录变更请求]
    B -->|聚焦价值| B1[明确变更内容和原因]
    C -->|四原则三标准| C1[范围/进度/成本/质量影响]
    D -->|CCB/客户| D1[批准/拒绝/暂缓]
    E -->|责任人| E1[执行并验证]

变更分析四原则：影响范围、进度、成本、质量都要评估。

变更决策三标准：必须做？值得做？现在做？

7.2 变更管理话术

阶段	话术
识别	“收到，我先记录为变更请求 CR-001，稍后统一评估。”
澄清	“为了准确评估，能否确认一下：这个功能的使用场景是什么？必须在哪个版本上线？”
分析	“这个变更会影响 3 个模块，预计增加 5 人天，测试周期延长 2 天，风险等级为中。”
决策	“基于影响评估，建议本期不做，放到二期；如果必须做，需要追加预算并调整验收时间。”
实施	“变更已批准，这是更新后的计划和责任人，请大家按新基线执行。”

八、风险管理：提前把坏事想清楚

风险不是等问题发生了再处理，而是提前识别、评估、应对、监控。

8.1 风险管理四步法

flowchart LR
    A[风险识别] --> B[风险评估]
    B --> C[风险应对]
    C --> D[风险监控]
    D --> A

    A -.->|工具| A1[头脑风暴 / 检查表 / 经验教训]
    B -.->|维度| B1[概率 × 影响]<br/>高/中/低
    C -.->|策略| C1[规避 / 转移 / 减轻 / 接受]
    D -.->|动作| D1[跟踪 / 更新 / 触发应急]

8.2 风险应对策略

策略	含义	例子
规避	不做或换方式，彻底消除风险	不用未经验证的新技术
转移	把风险后果转给第三方	买保险、签固定总价合同
减轻	降低概率或影响	增加测试、提前采购关键设备
接受	不采取措施，准备应急储备	预留缓冲时间或预算

8.3 风险登记册模板

风险 ID	风险描述	概率	影响	等级	应对措施	责任人	状态
R01	第三方接口延迟	中	高	高	提前 2 周启动对接，准备 mock	张三	跟踪
R02	核心人员离职	低	高	中	建立备份机制，文档化	李四	跟踪
R03	客户需求频繁变更	高	中	高	固化 SOW，严格变更流程	PM	跟踪

8.4 风险沟通话术

“我们在风险评审中发现，第三方 DRM 对接存在延期可能。当前概率评估为中等，但一旦发生会影响整个验收。我们的应对措施是：本周内完成技术预研，并准备一套降级方案。责任人是我，下次周会同步进展。”

九、项目验收与关闭

项目不是上线就结束了，验收和关闭同样重要。

9.1 验收流程

flowchart TD
    A[完成全部交付件] --> B[配置审核]
    B --> C[入口条件审核]
    C --> D[提交验收申请]
    D --> E[客户组建验收组]
    E --> F[正式验收测试]
    F --> G{是否通过?}
    G -->|是| H[签署验收报告]
    G -->|否| I[问题整改]
    I --> F
    H --> J[项目关闭 / 转维]

9.2 验收前 PM 自检清单

合同 / SOW 约定的交付件是否全部完成？
测试报告、用户手册、运维文档是否归档？
已知缺陷是否有客户书面确认？
验收申请是否正式发出？
验收标准和测试用例是否与客户对齐？

9.3 项目关闭三件套

验收报告：客户签字，确认交付完成。
经验教训：好的坏的都记下来，下次不再踩坑。
转维交接：让运维/运营团队能接手。

十、案例复盘：为什么 A项目能成，Transvision项目不行

10.1 A项目：成功交付的关键

范围清晰：直播/DVR/catchup + 付费/预付费模式 + launcher/广告/getsapp。
计划可控：首期 3 个月 12 天，二期 3 个月，节奏稳定。
沟通及时：与客户保持良好及时的沟通。
风险质量进度都管住了：最终客户满意度高，用户增长迅速。

启示：项目成功 = 清晰范围 + 可控计划 + 有效沟通 + 风险管理。

10.2 Transvision项目：为什么不可交付

需求边界不清：全终端、双 DRM、多支付、广告、CP Dashboard、用户割接、时移、ABR……堆在一起。
成本无法核算：套餐定价与 XXX公司成本核算难以达成明确结论。
商业可行性存疑：POC 持续近一年，成本约 5000 美金，最终被拒。

启示：PM 要敢于在早期说“这个项目不可交付”——不是消极，而是对组织负责。项目经营责任者的角色要求 PM 评估商业可行性，而不仅是执行。

十一、给 PM 新人的三条成长建议

1. 先建立“流程感”，再追求“灵活性”

新人常犯的错误是觉得流程麻烦、想快速跳过。但流程是保护你的：变更流程保护你不被客户随意改需求，风险流程保护你不被突发问题打懵。先把流程跑熟，再谈灵活裁剪。

2. 把“人”当成项目最重要的风险

进度延期、需求变更、技术问题，归根到底都是人的问题。PM 70% 的时间要花在沟通上：对齐期望、解决冲突、激励团队、管理客户。

3. 练习“结构化表达”

PM 的话术不是油滑，而是结构化：

结论先行
给数据和事实
讲影响和选项
明确下一步和责任人

十二、总结：一张图看懂 PM 的核心工作

flowchart TB
    A[项目目标] --> B[范围管理]
    B --> C[WBS 分解]
    C --> D[进度/成本/质量计划]
    D --> E[执行 + 监控]
    E --> F[沟通 / 风险 / 变更]
    F --> G{验收通过?}
    G -->|是| H[项目关闭]
    G -->|否| I[整改 / 变更]
    I --> E

    style A fill:#e0f2fe
    style H fill:#dcfce7
    style I fill:#fee2e2

PM 的核心能力可以概括为三句话：

把事情做对：理解需求、拆清范围、管好进度成本质量。
把人对齐：识别干系人、制定沟通策略、化解冲突。
把风险控住：提前识别、量化影响、准备预案。

如果你刚转 PM，别急着背 49 个过程。先把这篇文章里的角色认知、五大过程组、WBS、沟通、变更、风险管理跑起来，你就已经比大多数新人走得更稳了。

参考：本文部分内容结合《XXX PM 角色认知》培训材料与 PMBOK 第七版/第六版项目管理知识体系整理，融入一线 OTT 项目交付经验。

软件工程 on 方糖猫Blog

十年前泡论坛啃书，现在问 AI：软件知识的分层与获取地图

十年前泡论坛啃书，现在问 AI：软件知识的分层与获取地图

一、Spring Boot 和 Netty，其实是两个层面的东西

二、四层知识，四个时代的入口

原理层：Reactor、CAP、B+ 树、TCP

组件层：Netty 的 EventLoop、Redis 的持久化、Kafka 的副本协议

版本层：Spring Boot 3 的配置项、Redis 7 的新命令

方案层：秒杀、订单幂等、分布式事务

三、把例子走完：秒杀系统的四层拆解

四、趋势在哪看

五、AI 时代真正改变的三件事

《领域驱动设计·精简版》详解：零基础读懂 DDD 的核心概念

《领域驱动设计·精简版》详解：零基础读懂 DDD 的核心概念

第 1 章 简介：软件为什么会偏离领域

领域与领域模型

书里的案例：空中交通监控系统

第 2 章 通用语言（Ubiquitous Language）

翻译是万恶之源

用模型当语言的骨架

第 3 章 模型驱动设计（Model-Driven Design）

分层架构

七个构造块

① 实体（Entity）：靠"身份"区分

② 值对象（Value Object）：靠"属性"区分

③ 服务（Service）：无家可归的操作

④ 模块（Module）：高内聚、低耦合的分组

⑤ 聚合（Aggregate）：一致性的边界

⑥ 工厂（Factory）：封装"怎么造"

⑦ 资源库（Repository）：封装"怎么找"

第 4 章 面向深层理解的重构

第 5 章 保持模型一致性：大型项目的生存法则

界定的上下文（Bounded Context）

上下文之间的六种关系模式

精炼（Distillation）：找到核心域

第 6 章 专访 Eric Evans

全书总结：一张 DDD 知识地图

《领域驱动设计》精简版：一张图看懂 DDD，引用开源 ddd-demo

《领域驱动设计》精简版：一张图看懂 DDD，引用开源 ddd-demo

一、为什么需要 DDD？

二、一张图：DDD 战略-战术全景

三、战略设计：先画地图，再打仗

3.1 领域 = 问题空间 + 解决方案空间

3.2 限界上下文 Bounded Context

3.3 上下文映射模式

3.4 从限界上下文到微服务边界

映射原则

拆分的启发条件

案例：B2C 电商的微服务边界划分

第一步：识别子域

第二步：定义限界上下文与统一语言

第三步：映射为微服务

第四步：选择上下文映射模式

常见反模式

四、战术设计：在限界上下文里建模型

4.1 核心概念关系图

4.2 实体 Entity vs 值对象 Value Object

五、完整设计 Demo：电商订单上下文

5.1 充血模型 vs 贫血模型对比

六、分层架构：代码放哪里？

七、聚合设计：四条黄金规则

八、领域事件：跨聚合/上下文的胶水

九、常见反模式与纠正

十、什么时候用 DDD，什么时候不用？

十一、实战案例：新项目从 0 到 1 落地 DDD

11.1 项目背景与目标

11.2 第一步：识别领域与子域

11.3 第二步：划分限界上下文

11.4 第三步：推导微服务边界

11.5 第四步：选择上下文映射模式

11.6 第五步：充血模型 vs 贫血模型决策

11.7 第六步：DDD 是否可以裁剪？

场景 1：只用战略设计，战术设计从简

场景 2：只用战术设计，在已有边界内建模

场景 3：战略 + 战术都用，但不用高级模式

裁剪原则

11.8 落地时间线建议

十二、一句话总结

参考

设计模式全景图：六大原则、23 种 GoF 模式与 J2EE 模式

第 1 章简介：软件为什么会偏离领域

第 2 章通用语言（Ubiquitous Language）

第 3 章模型驱动设计（Model-Driven Design）

第 4 章面向深层理解的重构

第 5 章保持模型一致性：大型项目的生存法则

第 6 章专访 Eric Evans