各位同学，大家下午好！
欢迎来到今天的讲座。我是你们的老朋友，一个在代码泥潭里摸爬滚打多年，头发比项目需求还少的资深编程专家。
今天我们要聊一个听起来很学术，但实际上能救你们狗命的话题——React 领域驱动设计（DDD）：如何把你的 UI 层和那坨该死的业务逻辑分家。
我知道，你们心里可能在想：“专家，别扯那些虚头巴脑的理论了，我就想写个 React 组件，为什么非得搞什么 DDD？难道我以前写的代码是屎山，现在我要去盖摩天大楼吗？”
别急，先别急着把椅子扔向我。我们来聊聊为什么你的代码变成了“意大利面条”。
第一部分：当 React 遇上“上帝组件”
想象一下，你现在维护一个电商系统。有一天，老板说：“我要在这个购物车里加个功能，当总价超过 500 元时，自动打九折，并且给用户发个优惠券。”
你打开你的 CartPage.tsx，里面大概长这样：
import React, { useState, useEffect, useMemo } from 'react';
import axios from 'axios';
// 假设这是你的数据结构，全是 any，全是魔法
interface Item {
id: number;
price: number;
quantity: number;
}
export const CartPage: React.FC = () => {
const [items, setItems] = useState<Item[]>([]);
const [discount, setDiscount] = useState(0);
// 1. 获取数据
useEffect(() => {
axios.get('/api/cart').then(res => setItems(res.data));
}, []);
// 2. 业务逻辑混杂在 UI 逻辑里
const calculateTotal = () => {
let total = 0;
items.forEach(item => {
total += item.price * item.quantity;
});
// 业务规则：超过 500 打九折
if (total > 500) {
total = total * 0.9;
// 业务规则：发优惠券
setDiscount(10);
} else {
setDiscount(0);
}
return total;
};
// 3. UI 渲染
return (
<div className="cart-container">
<h1>我的购物车</h1>
<ul>
{items.map(item => (
<li key={item.id}>
{item.name} - ${item.price * item.quantity}
</li>
))}
</ul>
<div className="summary">
总价: ${calculateTotal()}
{discount > 0 && <span className="coupon">🎉 优惠券已发放！</span>}
</div>
</div>
);
};看，是不是很眼熟？这就是 90% 的 React 新手（甚至老手）写的代码。
问题出在哪？
- 耦合度爆炸： 你的 UI 组件在关心业务规则（
> 500，* 0.9）。如果老板改了需求：“哎呀，这次是满 1000 元打八折”，你不仅要改 JS 代码，还得改 UI 里的文案。如果需求是：“当总价超过 500 时，不仅打九折，还要发邮件给客服”，你现在的架构能做吗？不能。你只能硬塞进去。 - 不可测试： 你怎么测试
calculateTotal？你得先useEffect获取数据，再render，再检查 DOM 里的$符号？还是你写个单元测试，还得模拟整个 React 生命周期？太痛苦了。 - 状态混乱：
discount这个状态，它属于 UI 吗？属于业务吗？它好像既不是，也不是。它是个“副作用”的产物。
DDD 的核心思想很简单： 把业务逻辑和界面展示剥离开。就像把“计算器”和“显示器”分开一样。计算器只管算，显示器只管显示。如果计算器坏了，显示器依然可以亮着；如果显示器坏了，计算器依然可以算出 100。
第二部分：洋葱架构——我们的架构蓝图
在 React 里实现 DDD，我们不一定要搞出个复杂的六边形架构图挂在墙上。我们用洋葱架构的变体就好。
想象一个洋葱：
- 最外层（皮肤）： React 组件、样式、路由。这是给用户看的，容易变。
- 中间层（肉）： 业务逻辑、服务、状态管理。这是核心，比较稳定。
- 最内核（心）： 实体、值对象、领域规则。这是灵魂，绝对不能动。
我们的目标就是：洋葱是圆的，但我们的代码文件是分层的。
第三部分：核心层——让数据活起来
在 DDD 里，数据不是简单的 interface 或 class，它们是有生命的。它们有自己的行为。
1. 实体
在数据库里，User 只是个记录。但在 DDD 里，User 是个实体。实体意味着它有一个唯一标识，并且它的行为是由它自己定义的。
比如，一个“库存”实体。它不应该只是有个 quantity 属性，它应该有个方法叫 decrease(amount)。
不要写这样的代码：
// 坏代码
let stock = 10;
if (stock >= 5) {
stock -= 5;
console.log("剩余库存:", stock);
}我们要写这样的代码：
// domain/entities/Inventory.ts
export class Inventory {
private _quantity: number;
constructor(quantity: number) {
if (quantity < 0) {
throw new Error("库存不能为负数！这是常识！");
}
this._quantity = quantity;
}
// 获取数量（只读，防止外部直接修改）
get quantity(): number {
return this._quantity;
}
// 核心业务行为：扣减库存
// 这里包含了业务规则校验
decrease(amount: number): void {
if (amount <= 0) {
throw new Error("扣减数量必须大于 0");
}
if (this._quantity < amount) {
throw new Error("库存不足！别搞事情！");
}
this._quantity -= amount;
}
increase(amount: number): void {
if (amount <= 0) throw new Error("增加数量必须大于 0");
this._quantity += amount;
}
}看懂了吗？所有的验证逻辑都在方法内部。 这就是封装。UI 层根本不需要知道库存是否合法，它只需要调用 inventory.decrease(5)，如果抛出异常，那就说明逻辑出错了。
2. 值对象
值对象是那些没有唯一标识，但描述了属性的对象。比如 Money（金额）。
为什么要在 JS 里搞个 Money 类？因为 10.99 + 10.99 等于 21.98 吗？在 JavaScript 的浮点数运算里，它可能等于 21.980000000000004。这会让财务系统崩溃。
// domain/value-objects/Money.ts
export class Money {
constructor(private _amount: number) {
if (_amount < 0) throw new Error("钱不能是负数");
}
add(other: Money): Money {
return new Money(this._amount + other._amount);
}
multiply(factor: number): Money {
return new Money(this._amount * factor);
}
// 格式化输出
format(): string {
return `$${this._amount.toFixed(2)}`;
}
}现在，你的业务逻辑里全是 Money 对象，而不是 number。这保证了财务计算的绝对准确性。
第四部分：应用层与领域层——服务与仓储
有了实体和值对象，我们需要一个地方来组织它们。这就是服务。
1. 领域服务
领域服务用于处理那些不属于单个实体，但属于整个领域的逻辑。
比如“订单结算”。这个逻辑涉及到计算折扣、计算运费、检查库存、计算总价。这太复杂了，不能塞进 Order 类里，也不能塞进 Inventory 类里。
这时候，我们需要一个 OrderService。
// domain/services/OrderService.ts
import { Inventory } from '../entities/Inventory';
import { Money } from '../value-objects/Money';
export class OrderService {
constructor(
private inventoryService: InventoryService, // 假设这是个仓储接口
) {}
checkout(cartItems: CartItem[]): Result<Money> {
// 1. 验证库存
if (!this.inventoryService.checkAvailability(cartItems)) {
return Result.fail("库存不足");
}
// 2. 计算总价
let total = Money.from(0);
cartItems.forEach(item => {
total = total.add(item.price.multiply(item.quantity));
});
// 3. 应用折扣逻辑
if (total._amount > 500) {
total = total.multiply(0.9); // 九折
}
// 4. 扣减库存
this.inventoryService.decrease(cartItems);
return Result.ok(total);
}
}注意看，OrderService 里全是纯业务逻辑。它不关心 React 的 useState，不关心浏览器怎么渲染。它只关心：库存够不够？钱算对了吗？
2. 仓储接口
仓储是领域层和基础设施层的桥梁。它定义了“怎么存数据”，但具体怎么存（是存 Redis，还是存 MySQL，还是存 LocalStorage）由基础设施层决定。
// domain/repositories/IInventoryRepository.ts
export interface IInventoryRepository {
findById(id: string): Promise<Inventory>;
save(inventory: Inventory): Promise<void>;
decrease(id: string, amount: number): Promise<void>;
}为什么要接口？ 为了解耦！如果有一天你老板说：“咱们别用 MySQL 了，改用 MongoDB 吧。” 只要你的 MongoDB 实现了这个接口，你的领域层代码（OrderService）一行都不用改！这就是 DDD 的魅力。
第五部分：UI 层——React 的正确打开方式
现在，我们有了最核心的领域层。UI 层应该做什么？
UI 层应该依赖领域层，但不包含领域层。
1. 适配器模式
我们要把领域层的逻辑“适配”到 React 上。
这里有一个关键点：不要在 UI 层写业务逻辑！
UI 层只负责：接收用户点击 -> 调用领域层服务 -> 获取结果 -> 更新 UI。
我们使用 React 的 Hooks 来实现这个连接。
// ui/hooks/useCheckout.ts
import { useState } from 'react';
import { OrderService } from '../../domain/services/OrderService';
import { IInventoryRepository } from '../../domain/repositories/IInventoryRepository';
// 定义一个 Hook，用来管理 Checkout 的状态
export const useCheckout = (inventoryRepo: IInventoryRepository) => {
const [loading, setLoading] = useState(false);
const [error, setError] = useState<string | null>(null);
const [total, setTotal] = useState<number | null>(null);
const service = new OrderService(inventoryRepo);
const handleCheckout = async (cartItems: any[]) => {
setLoading(true);
setError(null);
try {
// 调用领域层服务
const result = service.checkout(cartItems);
if (result.isSuccess) {
setTotal(result.data._amount);
} else {
setError(result.error);
}
} catch (err) {
setError("未知错误");
} finally {
setLoading(false);
}
};
return { handleCheckout, loading, error, total };
};看，这个 Hook 里只有 loading、error 和 total。这些是 React 的状态。业务逻辑（checkout 的计算、库存检查）完全被隔离在 OrderService 里。
2. 组件实现
现在我们的 UI 组件就变得非常干净了：
// ui/components/CheckoutPage.tsx
import React from 'react';
import { useCheckout } from '../hooks/useCheckout';
import { IInventoryRepository } from '../../domain/repositories/IInventoryRepository';
// 模拟一个仓储实现（基础设施层）
class LocalStorageInventoryRepo implements IInventoryRepository {
// ... 实现省略 ...
}
export const CheckoutPage: React.FC = () => {
const cartItems = [
{ id: '1', price: 600, quantity: 1 }, // 总价 600，会触发折扣
{ id: '2', price: 100, quantity: 1 },
];
// 注入依赖
const repo = new LocalStorageInventoryRepo();
const { handleCheckout, loading, error, total } = useCheckout(repo);
return (
<div className="checkout">
<h1>结账</h1>
<button onClick={() => handleCheckout(cartItems)} disabled={loading}>
{loading ? '处理中...' : '提交订单'}
</button>
{error && <div className="error">{error}</div>}
{total !== null && <div className="success">应付金额: ${total.toFixed(2)}</div>}
</div>
);
};对比一下：
- 以前的代码：你在 UI 组件里写
if (total > 500)，修改 UI 还要改逻辑。 - 现在的代码：UI 组件只是个传声筒。老板说“满 1000 打八折”，你只需要去改
OrderService里的multiply(0.8)，整个系统自动生效，不需要动一行 JSX。
第六部分：深入探讨——如何处理异步与副作用
这是 React 开发者最容易晕的地方。在 DDD 里，我们怎么处理 API 请求？
答案：把 API 请求放在基础设施层，通过仓储接口暴露给领域层。
// infrastructure/repositories/ApiInventoryRepository.ts
import { IInventoryRepository } from '../../domain/repositories/IInventoryRepository';
import { Inventory } from '../../domain/entities/Inventory';
export class ApiInventoryRepository implements IInventoryRepository {
async findById(id: string): Promise<Inventory> {
// 这里是真正的网络请求
const response = await fetch(`/api/inventory/${id}`);
const data = await response.json();
// 转换成领域实体
return new Inventory(data.quantity);
}
async decrease(id: string, amount: number): Promise<void> {
await fetch(`/api/inventory/${id}/decrease`, {
method: 'POST',
body: JSON.stringify({ amount })
});
}
}注意到了吗？IInventoryRepository 接口里全是 async 方法。这意味着我们的领域层（OrderService）也必须变成 async。
// domain/services/OrderService.ts (修改版)
export class OrderService {
constructor(private inventoryRepo: IInventoryRepository) {}
async checkout(cartItems: CartItem[]): Promise<Result<Money>> {
// ...
// 这里需要 await 仓储操作
await this.inventoryRepo.decrease(cartItems[0].id, 5);
// ...
}
}然后在 UI 层的 Hook 里处理 await：
const handleCheckout = async (cartItems: any[]) => {
setLoading(true);
try {
const result = await service.checkout(cartItems); // 等待领域层完成
// ...
}
}这就是清晰的分层：
- UI 层：处理用户交互，等待异步操作。
- 领域层：定义业务规则，调用仓储接口。
- 基础设施层：执行真实的网络请求，把数据变成领域实体。
第七部分：实战演练——重构一个“烂摊子”
假设我们有一个“用户注册”的模块。原来的代码是这样的：
// 烂代码
const RegisterForm = () => {
const [email, setEmail] = useState('');
const [password, setPassword] = useState('');
const [confirmPassword, setConfirmPassword] = useState('');
const handleSubmit = async (e) => {
e.preventDefault();
// 1. 简单校验
if (password !== confirmPassword) {
alert('密码不匹配');
return;
}
if (password.length < 6) {
alert('密码太短');
return;
}
// 2. API 请求
try {
await axios.post('/api/register', { email, password });
alert('注册成功');
} catch (err) {
alert('注册失败');
}
};
return <form onSubmit={handleSubmit}>...</form>;
};现在，我们用 DDD 重构它。
第一步：定义领域逻辑
// domain/entities/User.ts
export class User {
constructor(public email: string, public password: string) {
if (!email.includes('@')) throw new Error("邮箱格式不对");
}
}
// domain/services/ValidationService.ts
export class ValidationService {
static isPasswordStrong(password: string): boolean {
return password.length >= 6;
}
static passwordsMatch(p1: string, p2: string): boolean {
return p1 === p2;
}
}第二步：定义仓储
// domain/repositories/IUserRepository.ts
export interface IUserRepository {
save(user: User): Promise<void>;
}
// infrastructure/repositories/ApiUserRepository.ts
export class ApiUserRepository implements IUserRepository {
async save(user: User): Promise<void> {
await axios.post('/api/register', {
email: user.email,
password: user.password // 实际上应该加密，这里略过
});
}
}第三步：UI 层 Hook
// ui/hooks/useRegister.ts
import { useState } from 'react';
import { User } from '../../domain/entities/User';
import { ValidationService } from '../../domain/services/ValidationService';
import { IUserRepository } from '../../domain/repositories/IUserRepository';
export const useRegister = (repo: IUserRepository) => {
const [email, setEmail] = useState('');
const [password, setPassword] = useState('');
const [confirmPassword, setConfirmPassword] = useState('');
const [loading, setLoading] = useState(false);
const [error, setError] = useState<string | null>(null);
const handleSubmit = async (e: React.FormEvent) => {
e.preventDefault();
setLoading(true);
setError(null);
try {
// 1. 领域逻辑校验
if (!ValidationService.isPasswordStrong(password)) {
throw new Error("密码太短，至少6位");
}
if (!ValidationService.passwordsMatch(password, confirmPassword)) {
throw new Error("两次密码输入不一致");
}
// 2. 创建实体
const user = new User(email, password);
// 3. 调用仓储保存
await repo.save(user);
alert("注册成功！");
} catch (err: any) {
setError(err.message || "注册失败");
} finally {
setLoading(false);
}
};
return { email, setEmail, password, setPassword, confirmPassword, setConfirmPassword, handleSubmit, loading, error };
};看！
- UI 组件现在只需要处理表单输入、点击事件和显示错误。
- 业务规则（密码长度、密码匹配）被封装在
ValidationService里。 - 数据模型（User）是强类型的。
- API 调用被隔离在
ApiUserRepository里。
如果你的老板说：“我们要改成短信验证码注册，而不是邮箱密码”，你只需要：
- 新建一个
Phone实体。 - 修改
ValidationService，增加手机号格式校验。 - 修改
ApiUserRepository，把/api/register改成/api/register-phone。 - UI 层的
useRegisterHook 只需要改一下useState的类型。
领域层代码，几乎不需要动！
第八部分：状态管理——不要让 Redux 变成你的噩梦
很多同学引入 DDD 的时候，都会纠结：“我到底该用 Redux 还是 Zustand 还是 Context？”
如果你的业务逻辑很重，而且需要跨组件共享，DDD 建议你使用Zustand或者Jotai这类轻量级状态管理库，或者干脆用React Context。
但是！关键点来了：
在 DDD 架构下，你的状态应该是什么？
答案：状态 = 领域实体。
不要用 Redux 存一个 { name: "Alice", age: 25 }。存一个 User 实例。
// store/useUserStore.ts
import { create } from 'zustand';
import { User } from '../domain/entities/User';
import { IUserRepository } from '../domain/repositories/IUserRepository';
interface UserState {
currentUser: User | null;
login: (email: string, password: string, repo: IUserRepository) => Promise<void>;
}
export const useUserStore = create<UserState>((set) => ({
currentUser: null,
login: async (email, password, repo) => {
// 这里可以调用领域服务进行登录验证
const user = new User(email, password); // 模拟登录成功
set({ currentUser: user });
},
}));这样，你的状态管理器里存的都是纯业务对象，而不是为了渲染 UI 而凑出来的数据。
第九部分：测试——DDD 的真正福利
这也是我最喜欢 DDD 的地方。
以前写测试，我得写个 render(<MyComponent />)，然后用 screen.getByText 去找 DOM 元素。如果 UI 变了，测试就挂了。
现在，写单元测试，我只需要一个简单的 JS 文件：
// tests/domain/services/OrderService.test.ts
import { OrderService } from '../../domain/services/OrderService';
import { Inventory } from '../../domain/entities/Inventory';
describe('OrderService', () => {
let service: OrderService;
let mockRepo: any;
beforeEach(() => {
mockRepo = {
checkAvailability: jest.fn().mockReturnValue(true),
decrease: jest.fn(),
};
service = new OrderService(mockRepo);
});
it('should apply 10% discount when total > 500', () => {
// 给仓储返回一个库存
mockRepo.findById = jest.fn().mockReturnValue(new Inventory(100));
const result = service.checkout([{ id: '1', price: 600, quantity: 1 }]);
expect(result.isSuccess).toBe(true);
expect(result.data._amount).toBe(540); // 600 * 0.9
});
it('should fail if stock is insufficient', () => {
mockRepo.findById = jest.fn().mockReturnValue(new Inventory(0));
mockRepo.checkAvailability = jest.fn().mockReturnValue(false);
const result = service.checkout([{ id: '1', price: 100, quantity: 1 }]);
expect(result.isSuccess).toBe(false);
expect(result.error).toBe("库存不足");
});
});没有 React，没有 DOM，没有 <div />。只有纯粹的逻辑判断。这就是写测试的乐趣。
第十部分：如何起步——别贪多
我知道，看到这里你可能会想：“哇，要建这么多文件夹，写这么多类，我的项目会不会变得很重？”
答案是：是的，你的项目会变重。
但是，这种“重”是有价值的重。
起步建议：
- 从一个小模块开始： 别试图重构整个 App。找一个独立的模块，比如“购物车”或者“用户设置”。
- 实体先行： 先把
User、Product这些类写出来，定义好它们的行为。 - 提取服务： 把那些
useEffect里的逻辑提取出来，放到 Service 里。 - 慢慢迁移： UI 层慢慢去调用这些 Service。
记住： React 是个 UI 框架，不是业务框架。你的核心价值在于你解决业务问题的能力，而不是你写出多炫酷的 CSS 动画。
结语
各位同学，今天我们聊了很多。我们抛弃了“把所有东西都塞进组件里”的坏习惯，拥抱了洋葱架构。
我们看到了如何用 TypeScript 类来封装业务规则，如何用仓储模式解耦数据访问，如何让 UI 层变得纯粹而简单。
DDD 不是一种魔法，它是一种纪律。
它要求你：
- 诚实： 承认你的业务逻辑很复杂，不能只靠 UI 层来扛。
- 分离： 把业务逻辑从 UI 逻辑里剥离出来。
- 封装： 让数据对象自己管理自己的行为。
当你下次看到那个长达 800 行的 App.tsx 时，别再硬着头皮改了。深吸一口气，打开你的编辑器，新建一个 domain 文件夹。
把那个该死的逻辑，搬出去。让它们在阳光下奔跑，而不是躲在 UI 的阴影里瑟瑟发抖。
好了，今天的讲座就到这里。下课！
（记住，写代码的时候，别忘了保存。还有，把你的 any 类型都改成 T，或者更好的，string 或 number。这是对你自己的尊重。）