当前位置：首页 > news >正文

React 领域驱动设计：在 React 项目中划分领域逻辑层（Domain Layer）与 UI 呈现层

news 2026/7/16 13:15:31

各位同学，大家下午好！

欢迎来到今天的讲座。我是你们的老朋友，一个在代码泥潭里摸爬滚打多年，头发比项目需求还少的资深编程专家。

今天我们要聊一个听起来很学术，但实际上能救你们狗命的话题——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 />。只有纯粹的逻辑判断。这就是写测试的乐趣。