1. DDD 基础概念：领域、子域、核心域、通用域、支撑域的定义与区别
领域驱动设计（Domain-Driven Design，DDD）是一种以业务领域为核心驱动力的软件设计方法论。在深入支付订单聚合的实战之前，必须首先理解 DDD 中最基础的战略设计概念：领域、子域、核心域、通用域与支撑域。这些概念构成了划分业务边界、确定优先级和分配资源的理论基石。
1.1 领域（Domain）
领域是 DDD 中最上层的概念，指软件系统所要解决的整个业务问题空间。它定义了组织或系统所从事的业务范围。例如，对于一个在线支付平台，其领域就是“支付业务”，涵盖了从用户发起支付到资金清算完成的全部业务活动。
- 特点：领域是宏观的、完整的业务边界。
- 作用：为所有子域提供统一的业务上下文。
- 示例：电商系统的领域是“电子商务”，支付系统的领域是“支付处理”。
1.2 子域（Subdomain）
子域是对领域进行纵向或横向切割后得到的更小、更聚焦的业务问题空间。一个领域由多个子域组成，每个子域解决领域内一个特定的、相对独立的业务问题。
- 划分依据：按业务能力、业务流程或业务目标进行拆分。
- 关系：子域之间通过限界上下文（Bounded Context）进行隔离和协作。
- 示例：支付领域可拆分为“订单支付”、“退款处理”、“对账结算”、“风控审核”等子域。
💡 实战提示： 在支付系统中，不要试图用一个巨大的“支付领域”模型覆盖所有功能。正确的做法是先识别出所有子域，再为每个子域分配独立的限界上下文和团队。
1.3 核心域（Core Domain）
核心域是领域中最关键、最具竞争优势、最值得投入资源的子域。它是系统存在的根本原因，是业务差异化的核心体现。
- 特征：业务逻辑最复杂、变化最频繁、对业务成功影响最大。
- 策略：必须由最优秀的团队自主开发，投入最多的资源，进行深度建模。
- 示例：对于支付宝，“交易引擎”和“风控系统”是核心域；对于支付，“红包与转账”可能是核心域。
1.4 通用域（Generic Subdomain）
通用域是行业内普遍存在、没有业务差异化的子域。这类子域通常有成熟的解决方案或现成的商业产品，不需要团队投入大量精力进行自研。
- 特征：业务逻辑通用、标准化程度高、不构成核心竞争力。
- 策略：优先采购商业软件、使用开源方案或外包开发，避免重复造轮子。
- 示例：支付系统中的“用户认证”、“短信通知”、“日志记录”属于通用域。
1.5 支撑域（Supporting Subdomain）
支撑域是领域内必要但不具备核心竞争力的子域。它为核心域提供辅助功能，但本身不直接产生业务差异化价值。
- 特征：业务逻辑相对简单，但必须与核心域紧密配合。
- 策略：可以内部开发，但投入的资源应远少于核心域；优先考虑复用或简化实现。
- 示例：支付系统中的“商户入驻审核”、“结算报表生成”属于支撑域。
1.6 核心对比：四类子域的区别
| 维度 | 核心域 | 通用域 | 支撑域 |
|---|---|---|---|
| 业务价值 | 最高，决定竞争力 | 低，行业通用 | 中等，辅助核心 |
| 复杂度 | 高，业务逻辑深 | 低，标准化 | 中，定制但简单 |
| 开发策略 | 自研，投入最多资源 | 采购/开源/外包 | 自研，投入最少资源 |
| 变更频率 | 频繁，持续演进 | 稳定，极少变更 | 偶尔，按需调整 |
| 团队要求 | 领域专家+高级工程师 | 普通工程师即可 | 中级工程师 |
| 支付示例 | 交易引擎、风控 | 短信、日志、认证 | 商户审核、报表 |
1.7 领域与子域的关系图
下图展示了支付领域中“领域”与“子域”的层次结构，以及核心域、通用域、支撑域在其中的分布：
1.8 战略投资优先级矩阵
在支付系统架构设计中，不同子域的投资策略截然不同。下表总结了针对三类子域的资源分配原则：
| 子域类型 | 投资优先级 | 团队规模 | 技术选型策略 | 典型支付场景 |
|---|---|---|---|---|
| 核心域 | 最高（P0） | 最大，资深团队 | 自研，深度定制，持续重构 | 交易引擎、风控、路由 |
| 支撑域 | 中等（P1） | 较小，中级团队 | 自研，但保持简单，避免过度设计 | 商户审核、报表、对账 |
| 通用域 | 最低（P2） | 最小，甚至无专职团队 | 采购商业软件 / 使用开源 / 外包 | 短信、日志、认证、缓存 |
⚠️ 常见误区： 很多团队在项目初期将大量资源投入到通用域（如自研消息队列、自研配置中心），而忽视了核心域（如交易引擎）的深度建模。这会导致系统缺乏竞争力，且维护成本高昂。正确的做法是：核心域必须自研且投入最多，通用域尽量复用，支撑域保持轻量。
1.9 子域识别实战：支付订单聚合场景
以本课程的核心场景“支付订单聚合”为例，我们可以快速识别出以下子域：
- 核心域：订单聚合引擎（负责多笔子订单的合并、拆分、状态同步）、支付指令生成（根据聚合规则生成支付请求）。
- 支撑域：聚合规则配置（管理用户或商户的聚合策略）、聚合历史查询（提供审计和追溯能力）。
- 通用域：用户身份认证、操作日志、分布式锁（用于保证聚合操作的原子性）。
通过这种划分，团队可以清晰地知道：订单聚合引擎是必须投入精兵强将自研的核心资产，而日志和锁则可以直接使用公司现有的基础设施。