DDD领域驱动设计-子域

子域（Sub Domain）是整个业务领域的一部分。你可以认为子域代表的是一个单一的、有逻辑的领域模型。通常，大多数的业务领域都过于庞大和复杂，难以作为整体来分析，因此我们一般只关心那些必须在单个项目中涉及的子域。子域可以用来逻辑地拆分整个业务领域，这样你才能理解存在于大型复杂项目中的问题空间。

子域分类

子域可根据自身重要性和功能属性划分为三类子域：

• 核心域

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。

• 通用域

没有太多个性化诉求，同时被多个子域使用的通用功能子域是通用域。比如认证、权限等，这类应用很容易买到，没有企业特点限制，无需太多定制化。

• 支撑域

既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又是必需的支撑域。支撑域具有企业特性，但不具通用性，例如数据代码类的数据字典等系统。

如何分解子域

我们需要某种方法，将领域分解成逻辑上相互独立且没有交叉的子域。在这里的方法是通过产品愿景，识别核心域，进而识别核心域周边的子域。

识别核心域

由于核心域是最明显、最容易识别出来的子域，所以我们先从核心域开始。

每一个子域甚至每一个领域模型都是为了产品愿景而存在的。我们分解子域的第一步，就是从产品愿景中获取核心域。产品愿景包含“相对抽象的产品价值”，以及“实现该价值的主要功能”。其中，主要功能就是我们寻找核心域的依据。想象一下，如果要做MVP的话，我们会挑选最能够提供其核心价值的功能来开发，以验证产品价值。MVP往往就是核心域。

以活动运营系统为例，其产品愿景是通过各种吸引用户的优惠活动，以帮助客户通过活动提升用户量和知名度。其核心域是给客户提供吸引用户的多样的灵活的活动，包括活动形式、活动规则和多种奖励。

识别核心域周边的子域

核心域识别出来了，接下来就是识别核心域周边的子域。核心域往往不会独立存在，会有其他子域同核心域一起才能达成业务目标。这里需要回答的问题是：

• 有哪些子域是用来支撑核心域的？

  这些子域是帮助核心域更好的工作。例如提供审批流程以配置核心域，提供各种辅助功能更好的为核心域提供内容。

• 有哪些子域是核心域衍生出来的？

  核心域经常会产生一些数据，这些数据也有其价值。比如产生各种报表，活动奖励的发放记录。

• 有哪些子域是用来支撑或衍生自这些新识别出的子域的？

  用来支撑核心域的子域、以及核心域衍生的子域，也有各自的支撑子域和衍生子域。

识别出来的每个子域只对应一个问题，子域之间是相互独立的，没有交叉，不是包含关系。所以子域加起来就是整个领域。

也可以通过角色、时间等因素分解子域。解决不同角色的问题可能分属不同子域，比如用户参与活动、运营人员配置活动分属不同子域，两个子域的变化原因不同；不同时间使用的功能可能属于不到子域，比如先有运营人员配置活动，再有用户参与活动，配置活动和参与活动分属不同子域。

子域的粒度

理论上子域仍然可以被分解。例如活动子域可以分解为活动参与规则子域、奖励子域等。那么子域粒度多大是合适的呢？

我们希望每个子域可以解决某个特定的问题，让这个问题的解决方案都内聚在子域对应的限界上下文内，所以如果问题的再分解没有的边界并不清晰，建议先不分解。随意的拆分会导致成为“分布式单体”。

 关注“DDD落地”公众号，一起来学习DDD！