3. 支付订单领域分析：识别核心子域、通用子域与支撑子域
在领域驱动设计（DDD）的战略设计中，子域（Subdomain）是问题空间的核心分解单元。对于支付订单系统，准确识别每个子域的类型——核心、通用或支撑——直接决定了资源投入、技术选型与外包策略。本章将基于业务价值与差异化程度，对支付订单领域进行系统性子域划分。
3.1 子域分类原则
DDD 将子域分为三类，其判断标准如下表所示：
| 子域类型 | 业务价值 | 差异化程度 | 典型策略 |
|---|---|---|---|
| 核心子域 | 高——直接产生收入或核心竞争力 | 高——行业独有，需自研 | 投入最优资源，持续演进 |
| 通用子域 | 中——必需但无差异化 | 低——行业标准方案成熟 | 采购或采用开源产品 |
| 支撑子域 | 低——辅助业务运转 | 中——可自研或外包 | 简化实现，控制成本 |
判断要点：核心子域通常对应公司的“护城河”。例如，对于电商平台，订单履约是核心；对于支付公司，资金清分是核心。同一个业务域在不同企业中的分类可能完全不同。
3.2 支付订单领域子域全景
通过对支付订单全生命周期的分析，我们识别出以下四个主要子域：支付、订单、账户与风控。下图展示了它们之间的核心协作关系：
3.3 各子域详细分析
3.3.1 核心子域：支付
职责：处理资金从付款方到收款方的转移，包括支付指令构建、渠道路由、交易状态机管理。
- 关键能力：多渠道聚合（、支付宝、银行卡）、支付路由、对账与差错处理。
- 为何是核心：支付成功率直接影响交易转化率，支付体验是平台信任的基石。
- 典型聚合：
PaymentTransaction（支付交易聚合），包含支付单、支付流水、退款记录。
3.3.2 核心子域：订单
职责：管理商品/服务的购买契约，跟踪订单从创建到完成/取消的全生命周期。
- 关键能力：订单状态机、拆单/合单、库存预占、价格计算。
- 为何是核心：订单是业务流转的主线，订单数据的完整性直接关联财务与履约。
- 典型聚合：
Order（订单聚合），包含订单项、收货地址、支付信息快照。
3.3.3 核心子域：风控
职责：实时评估交易风险，拦截欺诈、盗刷、洗钱等异常行为。
- 关键能力：规则引擎、设备指纹、用户行为画像、黑白名单。
- 为何是核心：风控能力直接决定资金安全与合规成本，是金融级系统的生命线。
- 典型聚合：
RiskAssessment（风险评估聚合），包含风险因子、决策结果、处置动作。
3.3.4 通用子域：账户
职责：管理用户资金余额、冻结金额与交易流水。
- 关键能力：账户余额变更、资金冻结/解冻、流水记账。
- 为何是通用：账户体系在金融行业有成熟标准（如借贷记账法），可采购成熟的账务核心系统或使用开源方案。
- 典型聚合：
Account（账户聚合），包含账户余额、冻结明细、流水记录。
3.3.5 支撑子域：通知与审计
职责：向外部系统（商户、用户、监管）发送支付结果通知，并记录全链路操作日志。
- 关键能力：消息推送（HTTP回调、站内信）、重试机制、操作审计日志。
- 为何是支撑：通知与审计不直接产生业务价值，但为系统可靠性与合规性提供保障。
- 典型聚合：
Notification（通知聚合），包含通知目标、内容、状态、重试次数。
3.4 子域与限界上下文的映射
每个子域在解决方案空间对应一个或多个限界上下文（Bounded Context）。下表展示了推荐映射关系：
| 子域 | 限界上下文 | 通信方式 | 数据所有权 |
|---|---|---|---|
| 支付 | Payment Context | 事件驱动（支付成功事件） | 独立数据库 |
| 订单 | Order Context | REST API / 事件 | 独立数据库 |
| 风控 | Risk Context | RPC / 异步消息 | 独立数据库 |
| 账户 | Account Context | 事件驱动（记账指令） | 独立数据库 |
| 通知/审计 | Notification Context | 消息队列 | 独立数据库 |
实践建议：在微服务架构中，每个限界上下文通常对应一个独立的微服务。核心子域（支付、订单、风控）应分配最强的研发资源与最严格的代码评审；通用子域（账户）优先考虑集成成熟商业套件；支撑子域（通知）可使用轻量级实现，甚至外包。
3.5 子域依赖与数据流
下图展示了子域间的典型数据流与依赖关系，帮助理解后续聚合建模时的上下文映射：
3.6 本章小结
- 核心子域（支付、订单、风控）是系统竞争力的核心，必须自研并投入最优资源。
- 通用子域（账户）采用成熟方案，避免重复造轮子。
- 支撑子域（通知/审计）简化实现，关注可靠性与可观测性。
- 子域划分直接指导后续的聚合建模与限界上下文设计，是微服务拆分的首要依据。