DDD领域驱动设计学习总结-什么是领域、子域、限界上下文

核心比喻：公司组织

想象你要为一家大型电商公司（如亚马逊）构建一套完整的软件系统。

• 领域 = 整个公司的业务范围
• 子域 = 公司的各个专业部门
• 限界上下文 = 部门内部的具体工作流程、规则和“行话”

1. 领域

• 定义：一个组织所从事的业务范围以及其中包含的所有业务活动。它代表了你需要解决的全部问题空间。
• 核心问题：“我们到底在做什么生意？”
• 特点：范围最大，是业务全景图。
• 例子：对于亚马逊这样的公司，其领域就是 “电子商务”。这涵盖了从商品上架、用户浏览、购物车、下单、支付、仓储、配送到售后客服的所有事情。

2. 子域

• 定义：为了管理庞大的领域，将其拆分成更小、更专注的业务能力区域。每个子域负责解决领域中的一个特定问题。
• 核心问题：“我们的业务由哪些核心部分组成？”
• 分类（非常重要）：
  • 核心子域：公司的核心竞争力，是业务的独特价值和差异点所在。应该投入最好的资源。
    • 电商例子：商品推荐系统。这是亚马逊成功的关键，利用算法提供个性化推荐。
  • 通用子域：业务必需，但非独有，通常是行业通用问题。可以考虑购买现成解决方案或投入较少资源。
    • 电商例子：用户身份认证、支付网关集成。每个电商都需要，但不是核心竞争力。
  • 支撑子域：支撑核心业务运作，但不是核心。通常是为内部服务的定制化系统。
    • 电商例子：物流路线规划系统、内部客服工单系统。它们支持配送和售后，但本身不直接产生独特商业价值。
• 特点：子域是纯业务概念，与技术实现无关。它告诉你“业务是什么”。

3. 限界上下文

• 定义：一个明确的边界，在边界之内，一套特定的领域模型（包括实体、值对象、领域服务等）和通用语言 是适用的、一致的、无歧义的。它是系统的解决方案空间在子域内的具体实现。

• 核心问题：“在某个具体部分，我们如何构建软件来实现它？”

• 关键点：

  1. 边界：BC是一个显式边界，可以是微服务、模块、包等。边界内外，同一个词可能有不同含义。
  2. 通用语言：在BC内部，业务人员和开发人员使用一套统一、精确的语言进行交流。这个语言会直接映射到代码的类名、方法名上。
  3. 领域模型：每个BC都拥有自己独立的、为该特定上下文优化的领域模型。

• 例子：

  • 在 “商品”子域 中，你可能会建立一个 “商品目录上下文” 。在这里，“商品”这个模型拥有丰富的属性：标题、描述、多维度分类、品牌、规格参数等。
  • 在 “订单”子域 中，你会建立一个 “订单处理上下文” 。在这里，“商品”可能只是一个简化的模型：商品ID、名称、快照价格、数量。它不关心商品的具体描述，只关心下单那一刻的信息。
  • 在 “物流”子域 的 “包裹追踪上下文” 中，“商品”可能进一步简化为：商品SKU、重量、体积。它只关心物流所需的物理属性。

  这就是限界上下文的核心价值：它承认并隔离了“同一个事物在不同场景下有不同视角和模型”这一现实。

三者的关系与总结

通俗流程：

1. 划定领域：我们做电商。
2. 划分子域：电商业务主要由“商品”、“营销”、“订单”、“支付”、“仓储”、“物流”、“客服”等子域构成。其中，“商品推荐”是核心子域，“支付”是通用子域，“客服工单”是支撑子域。
3. 定义限界上下文：为每个子域设计具体的软件实现边界。例如，“订单”子域可能拆分为 订单处理上下文、订单履约上下文、订单查询上下文 等多个BC，每个都是一个独立的微服务或模块，拥有自己独立的“订单”模型。

一个子域可能对应一个或多个限界上下文。在复杂系统中，通常一个核心子域会因为其复杂性而被设计成多个BC。而一个简单的支撑子域可能只需要一个BC来实现。

核心价值

• 降低复杂性：通过分解（子域）和隔离（BC）来管理庞大系统。
• 统一语言：在BC内消除业务与技术的沟通鸿沟。
• 明确边界：避免模型混淆，让系统架构清晰，团队职责明确。
• 指导微服务拆分：BC是微服务拆分的最佳自然边界。

简单说：领域是你想做的事，子域是你做这件事必须搞定的几个大环节，限界上下文是你在每个环节里具体怎么干（并且保证干的时候大家说的、想的、代码写的都是一回事）。