1. DDD 基础概念:领域、子域、核心域、通用域、支撑域的定义与关系

领域驱动设计(Domain-Driven Design,DDD)是一种以业务领域为核心的软件建模方法。在开始划分限界上下文和模块之前,必须首先理解 DDD 中最基础的一组概念:领域、子域、核心域、通用域 和 支撑域。这些概念构成了 DDD 战略设计的基石,决定了后续所有架构决策的方向。

1.1 领域(Domain)

领域 是软件系统所要解决的那个真实业务世界。它不是一个抽象的技术概念,而是企业或组织实际运营的某个业务范围。例如:

  • 电商平台的领域是“在线零售”
  • 银行系统的领域是“金融服务”
  • 物流系统的领域是“供应链与运输管理”

一个领域通常包含多个相互关联的业务活动、规则、流程和参与者。DDD 的核心思想就是让软件模型紧密对齐这个真实领域,而不是被技术框架牵着走。

关键认知: 领域不是“系统功能清单”,而是业务专家头脑中的知识体系。建模的第一步是学习领域语言(Ubiquitous Language),而不是画数据库 ER 图。

1.2 子域(Subdomain)

一个大型领域往往过于复杂,无法一次性建模。DDD 将整个领域拆分为多个 子域,每个子域对应领域中的一个相对独立的业务模块或问题空间。子域之间通过明确的边界进行隔离,每个子域有自己的业务逻辑和术语。

子域划分的典型依据包括:

  • 业务流程边界: 订单处理、库存管理、支付结算各是一个独立流程
  • 业务职责边界: 客户管理、商品管理、营销活动各是一个职责域
  • 组织架构边界: 康威定律指出,系统结构会复制组织沟通结构
实践提示: 在 Go 项目中,子域通常对应一个独立的 internal/ 包或模块。例如 internal/order、internal/payment、internal/inventory。

1.3 核心域、通用域、支撑域

并非所有子域对业务的价值相同。DDD 根据子域对业务战略的重要性,将其分为三类:

类型 定义 业务价值 典型特征 Go 项目中的处理方式
核心域 系统最核心、最具竞争力的业务逻辑 最高,直接决定产品差异化 复杂、独特、需要大量领域专家投入 投入最多资源,精细建模,internal/core/
通用域 业界已有成熟解决方案的通用业务 中等,不构成竞争优势 标准化、可采购或使用开源方案 优先使用现成库或 SaaS,internal/common/
支撑域 为支持核心域而存在的辅助业务 较低,但不可或缺 定制化但逻辑相对简单 适度建模,internal/support/
常见误区: 很多团队把大量时间花在通用域(如用户认证、日志、通知)上,却忽略了核心域的深度建模。DDD 要求你识别出“什么才是真正让公司赚钱的部分”,然后把最好的工程师和最深的思考留给核心域。

1.4 四者关系:从领域到子域再到战略分类

下图展示了领域、子域、核心域/通用域/支撑域之间的整体关系:

领域、子域与战略分类关系图 领域(Domain):在线零售 核心域(Core Domain) 订单履约引擎 • 智能拆单与合单 • 库存预占与释放 • 履约优先级调度 投入 60% 研发资源 通用域(Generic Domain) 用户认证与权限 • OAuth2 / SSO 集成 • RBAC 权限模型 • 多租户隔离 使用开源库 Keycloak 支撑域(Supporting Domain) 商品信息管理 • 商品 CRUD • 类目与属性管理 • 商品搜索索引同步 定制开发,逻辑简单 支撑域(Supporting Domain) 物流追踪集成 • 对接多家快递 API • 运单状态同步 • 异常件处理 适配器模式封装 说明:一个领域包含多个子域;每个子域根据战略重要性被归类为核心域、通用域或支撑域。

1.5 战略优先级与资源分配

DDD 战略设计的一个核心原则是:差异化投资。不同类型的子域应该获得不同级别的关注和资源:

  1. 核心域: 投入最资深的工程师、最深入的领域建模、最精细的测试覆盖。这是你的护城河。
  2. 通用域: 优先采购或使用成熟开源方案,避免重复造轮子。例如认证用 Keycloak、支付用 Stripe SDK。
  3. 支撑域: 适度建模,保持简单。只要满足核心域的需求即可,不必过度设计。
Go 项目落地建议: 在 cmd/ 或 internal/ 目录下,按子域组织包结构。核心域包名应体现业务概念(如 fulfillment),而非技术概念(如 service)。通用域和支撑域可以放在 internal/pkg/ 或独立模块中。

1.6 常见误解澄清

误解 正确理解
“领域就是数据库表结构” 领域是业务知识和行为,不是数据存储结构
“核心域就是最复杂的模块” 核心域是业务上最重要的模块,复杂度和重要性不一定成正比
“通用域可以随便写” 通用域虽然不构成竞争优势,但出错会影响整个系统稳定性
“支撑域不需要建模” 支撑域仍然需要清晰的边界和接口,只是建模深度可以降低
“子域划分一次完成” 子域划分是迭代过程,随着对业务理解的加深会不断调整

1.7 本章小结

领域、子域、核心域、通用域、支撑域是 DDD 战略设计的五个基础概念。它们之间的关系可以概括为:

  • 领域 是你要解决的整个业务问题空间
  • 子域 是领域内部按业务边界切分出的独立问题模块
  • 核心域 是子域中业务价值最高、决定产品竞争力的部分
  • 通用域 是业界已有成熟方案的标准化子域
  • 支撑域 是为核心域提供辅助支持的定制化子域