领域驱动设计

DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

• DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

• 微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

战略设计核心构件

域类型	定义	特征	识别技巧	案例
核心域	业务核心竞争力所在	- 独特业务价值 - 高投入优先级 - 战略差异点	是否直接解决核心业务问题？	电商的订单交易系统 金融的风控引擎
支撑域	辅助核心域运作的定制化功能	- 支撑核心流程 - 需定制开发 - 非通用方案	是否为专属业务需求且无法外包？	电商的促销规则引擎 物流的路径优化系统
通用域	行业通用解决方案	- 现成方案可用 - 低业务差异性 - 避免重复造轮子	是否有成熟产品/开源方案？	用户认证模块 支付网关集成 日志监控
子域	大领域分解的独立问题域	- 逻辑功能单元 - 可对应限界上下文 - 高内聚低耦合	能否用一句话描述清晰职责？	电商的库存域、商品域、会员域...
限界上下文	子域的具体解决方案边界	- 明确系统边界 - 统一语义环境 - 独立模型/代码	领域模型是否在此范围内无歧义？	订单上下文、物流上下文、支付上下文...

战术设计核心构件

概念	描述
实体（Entity）	具有唯一标识和生命周期的对象（如 User、Order）。
值对象（Value Object）	无唯一标识，通过属性描述特征（如 Money、Address）。
聚合（Aggregate）	一组关联对象的集合，由聚合根统一管理（如 Order 聚合包含 OrderItem）。
聚合根（Aggregate Root）	聚合的入口点，负责维护内部一致性和事务边界。
领域服务（Domain Service）	处理跨聚合或无状态的核心业务逻辑（如 TransferService）。
领域事件（Domain Event）	表示领域中发生的重要事件（如 OrderCreated），用于解耦系统。
资源库（Repository）	管理聚合的持久化与检索（如 IOrderRepository）。
工厂（Factory）	封装复杂对象的创建逻辑（如 OrderFactory）。

协作与模式

概念	描述
统一语言（Ubiquitous Language）	开发人员与领域专家共同创建的精确术语，确保沟通一致性。
分层架构（Layered Architecture）	典型分层： - 用户界面层（UI） - 应用层（协调任务） - 领域层（业务逻辑） - 基础设施层（技术实现）
防腐层（Anti-Corruption Layer）	隔离外部系统或遗留代码，避免污染领域模型（如适配第三方支付接口）。
领域模型（Domain Model）	对业务领域的抽象表示，包含实体、值对象、规则等。

领域模型设计模式

概念	描述	示例
充血模型（Rich Model）	将业务逻辑内聚到领域对象中（实体/值对象），而非服务层。	Order.cancel() 方法封装状态校验、事件发布逻辑，而非在 OrderService 中实现。
贫血模型（Anemic Model）	反模式：领域对象仅有 getter/setter，业务逻辑集中在服务层。	Order 类只有属性，业务逻辑全在 OrderService 中。
领域能力（Domain Capability）	将领域内的特定能力抽象为独立对象（策略模式）。	PricingStrategy 接口实现不同定价策略（会员价、促销价）。
规格模式（Specification）	封装业务规则为可组合、可重用的逻辑单元。	OrderIsCancelableSpec 检查订单是否满足取消条件（状态 + 超时时间）。

从真实场景理解 DDD

以下用一个 电商订单履约系统 的真实场景串联 DDD 所有核心概念，通过用户故事展开：

用户故事背景

作为消费者，我希望下单后系统自动扣减库存、计算优惠券、生成物流单，并在支付超时时自动取消订单，以确保购物体验流畅。

战略设计：划分业务边界

识别子域与限界上下文

子域类型	限界上下文（Bounded Context）	职责	用户故事关联
核心域	订单上下文（Order Context）	处理订单创建、状态流转、支付超时	用户下单、支付超时取消
支撑子域	库存上下文（Inventory Context）	管理商品库存扣减与回滚	下单后自动扣减库存
支撑子域	促销上下文（Promotion Context）	计算优惠券和折扣规则	下单时自动计算优惠券
通用子域	物流上下文（Shipping Context）	生成物流单号、对接快递公司	下单后生成物流单
上下文映射关系

战术设计：领域模型实现

订单上下文中的领域对象

概念	代码示例	职责	用户故事逻辑
实体	Order (订单)	管理订单状态、支付倒计时	记录订单状态（待支付/已取消）
值对象	CouponInfo (优惠券信息)	封装优惠券金额、使用规则	计算订单最终价格
聚合根	Order (作为聚合根)	管理 OrderItem 列表	确保订单项总价与优惠计算一致
领域服务	OrderCancelService	处理超时取消订单逻辑	30 分钟未支付自动取消订单
领域事件	OrderCreatedEvent	订单创建时触发	通知库存上下文扣减库存
	OrderCanceledEvent	订单取消时触发	通知库存回滚、物流取消发货
资源库	IOrderRepository	持久化订单聚合	保存订单状态到数据库
关键代码逻辑

// 领域事件驱动库存扣减
public class Order {
  public void createOrder() {
    // ... 订单创建逻辑
    DomainEventPublisher.publish(new OrderCreatedEvent(this.items)); 
  }
}

// 库存上下文监听事件
public class InventoryHandler {
  public void onOrderCreated(OrderCreatedEvent event) {
    inventoryService.reduceStock(event.getItems()); // 扣减库存
  }
}

协作与模式应用

跨上下文协作

协作模式	实现方式	用户故事场景
防腐层（ACL）	物流上下文封装第三方快递 API	生成物流单时转换数据格式，隔离外部变化
开放主机服务	促销上下文暴露 RESTful API	订单上下文通过 API 查询优惠券有效性
事件驱动	通过消息队列传递领域事件	订单取消事件触发库存回滚

关键 DDD 决策与业务价值

1. 聚合根守护一致性 Order 聚合根控制订单状态变更，确保状态流转合法（如已支付的订单不可取消）。

2. 领域事件解耦系统 订单取消后发布 OrderCanceledEvent，库存/物流上下文异步处理，避免分布式事务。

3. 统一语言消除歧义 开发与业务对齐术语：

   • “支付超时” = 订单创建后 30 分钟内未支付

   • “优惠券不可叠加” = 值对象 CouponRule 中实现 calculate() 逻辑

4. 上下文映射明确依赖 订单上下文通过防腐层调用物流服务，避免第三方 API 变更污染核心域。

用户故事完整流程

1. 用户提交订单 → 订单上下文创建 Order 聚合根

2. 发布 OrderCreatedEvent → 库存上下文扣减库存

3. 促销上下文返回优惠计算 → 订单生成最终价格

4. 用户 30 分钟内未支付 → 领域服务OrderCancelService 触发取消

5. 发布 OrderCanceledEvent → 库存回滚 + 物流取消发货

DDD 核心价值：通过限界上下文隔离业务复杂性，领域模型精确表达业务规则，事件驱动实现高内聚低耦合。