领域驱动设计（Domain-Driven Design, DDD） 简单来讲就是同过业务逻辑的边界来划分模块，通过定义领域事件和明确的交互方式实现模块之间的低耦合协作。
DDD 的核心概念
-
领域（Domain）
指业务问题的范围，即软件要解决的实际问题所处的领域（如电商、金融、物流等）。DDD 强调开发者需要深入理解业务，而非仅关注技术实现。 -
通用语言（Ubiquitous Language）
开发团队与业务专家共同定义一套统一的术语和概念，确保代码、文档、沟通中使用相同的语言，减少歧义。 -
限界上下文（Bounded Context）
将大系统划分为明确的边界，每个边界内使用独立的通用语言和模型。例如，电商系统中“订单”在支付上下文和物流上下文中可能含义不同。 -
领域模型（Domain Model）
在限界上下文内，通过对象（实体、值对象等）和规则抽象业务逻辑，模型是代码的直接反映。 -
分层架构（Layered Architecture）
通常分为：- 用户界面层（展示逻辑）
- 应用层（协调用例，不包含业务规则）
- 领域层（核心业务逻辑）
- 基础设施层（技术实现，如数据库、外部服务）
-
战术设计模式
- 实体（Entity）：具有唯一标识的对象（如用户 ID）。
- 值对象（Value Object）：通过属性定义的无标识对象（如货币金额）。
- 聚合根（Aggregate Root）：一组相关对象的入口，保证一致性。
- 领域服务（Domain Service）：处理无状态业务逻辑。
- 仓储（Repository）：封装数据持久化逻辑。
- 领域事件（Domain Event）：记录业务状态变化。
需要注意的陷阱：
- 事件泛滥：过度事件化可能导致系统难以跟踪（需配合事件溯源或 Saga 模式）。
- 业务边界模糊：不合理的限界上下文划分会带来事件循环依赖（如订单和库存互相监听事件）。
- 最终一致性：事件异步处理可能带来短暂状态不一致（需业务容忍）。