跳至正文
来两杯美式
返回

DDD 复杂业务系统设计(二):领域与子域,把“学校/课程/学员”拆成三件事再说

By 来两杯美式
发布于

前言

上一篇我们讲了为什么复杂业务必须从领域开始。这一篇我们把“领域”这个词拆开看:什么是领域,什么是子域,以及为什么要把子域再分三类。

这部分是 DDD 的地基,地基不稳,后面所有概念都会飘。

一、领域:不是“业务”的同义词

在 DDD 里,领域(Domain)是一个有边界的“问题空间”。它不是业务的全集,而是为了解决某类问题而划出来的一块范围

用在线教育 SaaS 举例,“在线教育”本身是一个大领域,但它太大了——大到我们没法在一个团队里、一个服务里把它做出来。

所以我们必须把它拆小

二、怎么拆?拆出来的叫“子域”

拆完之后,每一小块都叫子域(Subdomain)

比如在线教育平台,可以这样拆:

每个子域对应一个更小的问题空间,可以由一个相对独立的团队负责。

关键认知:拆子域不是为了“拆服务”,而是先把业务问题的颗粒度降下来。服务拆分是子域划分的“副产品”,不是目的。

三、不是所有子域都重要——三类子域

子域拆完,重要性是不一样的。这一点非常关键,因为它直接决定资源往哪里投

1. 核心域:公司的命根子

核心域是公司核心竞争力的所在。在在线教育行业:

核心域的特征:

2. 通用域:大家都在做,做得好不好不致命

通用域是被多个子域共用的通用能力。在线教育场景:

通用域的特征:

比如短信发送,用阿里云、腾讯云就够了,不需要自己造

3. 支撑域:必须做,但做得好不好用户感知不强

支撑域是业务必需但不通用、也不构成核心竞争力的能力。在线教育场景:

支撑域的特征:

四、为什么要分这三类?

最直接的理由:资源有限,方向要清楚

子域类型资源投入建设策略
核心域重金投入自主研发、最强团队、持续迭代
通用域少投入外购或使用成熟开源
支撑域适当投入简单实现即可,必要时升级

在在线教育行业里:

好钢用在刀刃上——这是 DDD 划分子域类型的最朴素目的。

五、怎么判断哪个是核心域?

没有标准答案,但有几个判断维度:

  1. 公司战略:领导讲话、年度规划里反复提到的能力,往往是核心域。
  2. 用户感知:用户付费的原因、留下不走的理由,对应的就是核心域。
  3. 竞争差异:同行都在做但我做不出差异化的,往往不是核心域。
  4. 替代成本:如果某能力被外部替代公司会死掉,那就是核心域。

以在线教育为例:

核心域的划分因公司战略而异,没有标准答案

六、案例:在线教育 SaaS 的子域划分

下面是我之前做过的一个项目,划分大致是这样:

在线教育平台(领域)
├── 课程域(核心域)            ── 课程、章节、课时
├── 报名域(核心域)            ── 选课单、订单、支付
├── 学习域(核心域)            ── 进度、笔记、答疑
├── 教学域(核心域)            ── 老师、排课、作业
├── 证书域(支撑域)            ── 证书模板、发放
├── 内容域(核心域)            ── 资料、附件、视频
├── 用户认证域(通用域)        ── 登录、注册、第三方登录
├── 通知域(通用域)            ── 短信、邮件、推送
└── 数据字典域(支撑域)        ── 配置项、枚举值

注意:子域是有边界的。同样是“课程”,在课程域里关注的是课程内容结构(章节、课时、知识点),在报名域里关注的是课程的可售卖属性(价格、有效期、限购)。它们是两个不同子域里的不同概念。

这个点很关键,下一篇讲限界上下文的时候我会展开。

七、常见误区

误区 1:所有子域都重要

现实是只有 20% 的子域值得花 80% 的资源。把所有子域都按核心域标准做,是 DDD 落地失败最常见的原因。

误区 2:子域一旦划分就不变

业务在演进,核心域也会变。早期可能课程不是核心,后期可能学习效果变成核心。子域划分要随战略调整而调整

误区 3:通用域不重要,可以随便做

通用域虽然不构成壁垒,但做不好会拖死核心域。比如认证系统挂了,所有服务都进不去。通用域要做到“稳”,但不需要“强”。

总结

这一篇我们讲了:

下一篇我们讲限界上下文——为什么同一个词在不同的子域里意思完全不同,以及这件事怎么决定微服务的边界。


分享这篇文章:
通过邮件分享这篇文章✓ 链接已复制
查看系列全部文章
  1. 01.DDD 复杂业务系统设计(一):为什么从“领域”开始,比从“数据库”开始更靠谱
  2. 02.DDD 复杂业务系统设计(二):领域与子域,把“学校/课程/学员”拆成三件事再说
  3. 03.DDD 复杂业务系统设计(三):限界上下文,为什么“课程”在教务和市场是两种东西
  4. 04.DDD 复杂业务系统设计(四):实体与值对象,把“学员”和“地址”放进代码的两种姿势
  5. 05.DDD 复杂业务系统设计(五):聚合与聚合根,一个“选课单”应该装多少东西
  6. 06.DDD 复杂业务系统设计(六):领域事件,让“作业提交”自动触发批改进度
  7. 07.DDD 复杂业务系统设计(七):分层架构,你的“业务代码”应该待在哪一层
  8. 08.DDD 复杂业务系统设计(八):整洁架构 vs 六边形架构 vs DDD 分层,我选哪一种
  9. 09.DDD 复杂业务系统设计(九):中台,在线教育平台到底应该共享什么
  10. 10.DDD 复杂业务系统设计(十):从战略到微服务,一张图跑通 DDD+中台+微服务
  11. 11.DDD 复杂业务系统设计(总结):从领域到微服务,一张图看懂 DDD 落地全流程

上一篇
DDD 复杂业务系统设计(三):限界上下文,为什么“课程”在教务和市场是两种东西
下一篇
DDD 复杂业务系统设计(一):为什么从“领域”开始,比从“数据库”开始更靠谱