各位同学大家下午好欢迎来到今天的讲座。我是你们的老朋友一个在代码泥潭里摸爬滚打多年头发比项目需求还少的资深编程专家。今天我们要聊一个听起来很学术但实际上能救你们狗命的话题——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] useStateItem[]([]); 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 classNamecart-container h1我的购物车/h1 ul {items.map(item ( li key{item.id} {item.name} - ${item.price * item.quantity} /li ))} /ul div classNamesummary 总价: ${calculateTotal()} {discount 0 span classNamecoupon 优惠券已发放/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[]): ResultMoney { // 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): PromiseInventory; save(inventory: Inventory): Promisevoid; decrease(id: string, amount: number): Promisevoid; }为什么要接口为了解耦如果有一天你老板说“咱们别用 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] useStatestring | null(null); const [total, setTotal] useStatenumber | 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 classNamecheckout h1结账/h1 button onClick{() handleCheckout(cartItems)} disabled{loading} {loading ? 处理中... : 提交订单} /button {error div classNameerror{error}/div} {total ! null div classNamesuccess应付金额: ${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): PromiseInventory { // 这里是真正的网络请求 const response await fetch(/api/inventory/${id}); const data await response.json(); // 转换成领域实体 return new Inventory(data.quantity); } async decrease(id: string, amount: number): Promisevoid { 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[]): PromiseResultMoney { // ... // 这里需要 await 仓储操作 await this.inventoryRepo.decrease(cartItems[0].id, 5); // ... } }然后在 UI 层的 Hook 里处理awaitconst 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): Promisevoid; } // infrastructure/repositories/ApiUserRepository.ts export class ApiUserRepository implements IUserRepository { async save(user: User): Promisevoid { 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] useStatestring | 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) Promisevoid; } export const useUserStore createUserState((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。这是对你自己的尊重。