DDD实战课
欧创新
人保高级架构师
立即订阅
4865 人已学习
课程目录
已完结 23 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 学好了DDD,你能做什么?
免费
基础篇 (5讲)
01 | 领域驱动设计:微服务设计为什么要选择DDD?
02 | 领域、子域、核心域、通用域和支撑域:傻傻分不清?
03 | 限界上下文:定义领域边界的利器
04 | 实体和值对象:从领域模型的基础单元看系统设计
05 | 聚合和聚合根:怎样设计聚合?
进阶篇 (6讲)
06 | 领域事件:解耦微服务的关键
07 | DDD分层架构:有效降低层与层之间的依赖
08 | 微服务架构模型:几种常见模型的对比和分析
09 | 中台:数字转型后到底应该共享什么?
10 | DDD、中台和微服务:它们是如何协作的?
答疑:有关3个典型问题的讲解
实战篇 (10讲)
11 | DDD实践:如何用DDD重构中台业务模型?
12 | 领域建模:如何用事件风暴构建领域模型?
13 | 代码模型(上):如何使用DDD设计微服务代码模型?
14 | 代码模型(下):如何保证领域模型与代码模型的一致性?
15 | 边界:微服务的各种边界在架构演进中的作用?
16 | 视图:如何实现服务和数据在微服务各层的协作?
17 | 从后端到前端:微服务后,前端如何设计?
18 | 知识点串讲:基于DDD的微服务设计实例
19 | 总结(一):微服务设计和拆分要坚持哪些原则?
20 | 总结(二):分布式架构关键设计10问
结束语 (1讲)
结束语 | 所谓高手,就是跨过坑和大海!
DDD实战课
登录|注册

02 | 领域、子域、核心域、通用域和支撑域:傻傻分不清?

欧创新 2019-10-16
你好,我是欧创新。
DDD 的知识体系提出了很多的名词,像:领域、子域、核心域、通用域、支撑域、限界上下文、聚合、聚合根、实体、值对象等等,非常多。这些名词,都是关键概念,但它们实在有些晦涩难懂,可能导致你还没开始实践 DDD 就打起了退堂鼓。因此,在基础篇中,我希望能带着你一起做好实践前的准备工作。
除此之外,我想说的是,这些名词在你的微服务设计和开发过程中不一定都用得上,但它可以帮你理解 DDD 的核心设计思想和理念。而这些思想和理念,在 IT 战略设计、业务建模和微服务设计中都是可以借鉴的。
那么,从这讲开始,我就会围绕以上这些 DDD 关键概念进行讲解,帮助你彻底理清它们与微服务的关系,了解它们在微服务设计中的作用。今天我们重点了解 DDD 的领域、子域、核心域、通用域和支撑域等重要概念。

如何理解领域和子域?

我们先看一下汉语词典中对领域的解释:“领域是从事一种专门活动或事业的范围、部类或部门。”百度百科对领域的解释:“领域具体指一种特定的范围或区域。”
两个解释有一个共同点——范围。对了!领域就是用来确定范围的,范围即边界,这也是 DDD 在设计中不断强调边界的原因。
在研究和解决业务问题时,DDD 会按照一定的规则将业务领域进行细分,当领域细分到一定的程度后,DDD 会将问题范围限定在特定的边界内,在这个边界内建立领域模型,进而用代码实现该领域模型,解决相应的业务问题。简言之,DDD 的领域就是这个边界内要解决的业务问题域。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(52)

  • vivi
    通用域和支撑域对应到企业系统是哪些呢?

    作者回复: 通用域是一些大家都需要用的通用系统,比如认证,权限等等,这类应用很容易买到,不需要做太多的定制化,没有企业特点。支撑域具有企业特性,但不具有通用性,比如数据代码类的数据字典等系统。

    2019-10-16
    1
    12
  • 祥敏
    您好,以我公司新启动的业务线“平安社区”为例,以安防设备为集成基础。安防设备和物联网平台却都是市场成熟厂家提供,划分为通用域;平安社区业务场景如人车双验、异常人员识别等个性化应用属于业务线的支撑域;人员数据、行为数据富有长期价值,这些视为核心域。如果未来在某个细分场景做到了领先且拥有市场壁垒,这样的业务也可能会从支撑域调整为核心域。
    所以,核心域、通用域、支撑域的划分本质是公司战略方向的体现,DDD是从战略到战术角度来进行架构设计的方法。

    作者回复: 是这样的。

    2019-10-29
    6
  • stg609
    老师你好,关于问题空间和解决方案空间一直不是很理解,子域的划分属于问题空间,而限界上下文则属于解决方案空间。
    但是这个所谓的问题空间和解决方案空间到底是啥?对于我们分析问题而言为何要划分这两种空间?

    作者回复: 你可以这么理解。问题空间的划分也就是子域的划分过程,实际上还是一个业务粗分过程,因为领域太大的话,你不方便对它进行分析和设计。
    只有问题空间小到一定程度后,你才可以熟悉的定义解决方案空间,在这个比较小的空间内进行事件风暴,找出领域对象,构建聚合,划分限界上下文,建立领域模型,再进行微服务的设计,也就是一个解决方案的形成过程。

    2019-10-22
    4
  • marker
    您好,我对领域驱动还算是入门比较早的了,看了您的文章后受益匪浅。总结和举例都非常到位,一句话表明了中心,不像其他的DDD课程,说得很官方。点个赞👍

    作者回复: 谢谢你的鼓励😄。

    2019-11-26
    2
  • huaweichen
    感谢老师非常深入浅出的桃树比喻。
    我们公司是做车险鉴定(Insurance Assessment)的。
    我们当时也初步开发了几个领域:
    授权领域:这个因该是属于通用域,认证、权限、登陆都在里面;还有日志领域,专门为决策层制定月报告的一些功能;支付和审核领域,也是一个通用域,里面包含了创建账单和发票、收款等。
    case领域,claim领域,assessment领域,repair领域等等,这几个是核心域,依次直接面对终端客户——保险方,索赔者,鉴定方,维修厂)

    支撑域我还不是很理解,不知道在实际应用中,支撑域和通用域有哪些典型的有区别的例子。

    作者回复: 个人感觉区分支撑域和通用域的意义不是太大。
    挖掘出核心域是有意义的,主要是明确战略重点,将重要的核心资源投入到核心域。
    支撑域和通用域在战略上基本上是同级的,有时候两者会转换。

    2019-11-05
    2
  • Geek_a91670
    有些领域边界特别模糊,不好划分,例如:某些子领域两边都靠,不知道怎么取舍

    作者回复: 看领域大小,不大的话可以考虑放在一个限界上下文内,做成一个微服务。比较大的话,可先做好聚合的边界,以后随时可以根据需要来拆分微服务。

    2019-10-18
    2
  • 段拙言
    这里没看限界上下文的概念,在桃树的例子中,细胞即为限界的上下文吗?还是说,器官,组织,细胞都是限界的上下文?

    作者回复: 你好,段拙言。还是你细心,不过不要纠结这里的限界上下文的概念,限界上下文是由它的语义边界来确定的。在DDD里面一个聚合可以是一个限界上下文,多个不同职能的聚合也可以组成为一个限界上下文,他们都在一个语义环境下。有的组织可能只有单一细胞,有的组织可能由多个不同功能的细胞组成的。我们重温一下生物课哈。由一种细胞所构成的均一组织。而由两种以上细胞构成的不均一的组织称为复合组织。特定功能(特定的语义环境)的组织基本上就可以对应到限界上下文。

    2019-10-16
    2
    2
  • Geek_88604f
    问题域和解决方案域是不是重合的呢

    作者回复: 大多数是重合的,但是如果受外界因素影响比较大的话,可能会一个问题域对应多个解决方案域。也就是一个子域可能会有多个微服务。

    2019-11-20
    1
  • Catwell
    13年以前基本是三层架构开发,13年后开始使用DDD,没系统的研究过,只是看了一些资料,我的理解是基于业务的属性,把原先的三层变成N个三层,相互间用接口或者API传输,不知道我这样理解对不对。

    作者回复: DDD包括战略和战术设计两个部分,战略设计完成领域建模,战术设计完成微服务设计。您说的应该属于战术设计的部分,DDD分层架构包括用户接入层、应用层、领域层和基础层四层,每层有不同的服务,职责不同。后面章节有详细介绍,请耐心等待。

    2019-10-16
    1
  • TH
    终于理解了DDD是可以逐级细化的,大的DDD里应该是可以套小的DDD,也理解了核心域的意义。对于如何确定边界还存在疑问,希望在后面的课程中得到解答。

    关于楼上朋友“子子域模型”的说法,其实只要定下一个大家都能理解的术语就行了,这跟DDD提倡的通用语言是一个道理。另外既然问题域可以逐级细化,那么在高层次看是子子域的范围,深入进去之后就成了“领域”,如果有必要的话也还可以在它下面再细分子域。不知这样理解对不对。

    作者回复: 非常正确。

    2019-10-16
    1
  • huayu00
    “”我们可以根据业务关联度以及流程边界将保险领域细分为:承保、收付、再保以及理赔等子域” --- 根据业务关联度以及流程边界细分的方法能介绍下吗?

    作者回复: 你好,huayu00。这一块的设计你可以参考传统的模块的设计方式。模块本身就是某类业务的功能聚合,具有一定的业务功能的内聚性。而对于很多业务场景来说,很多领域的边界就是流程的边界,比如商品、订单、货物,他们分别属于不同的流程,很自然的就形成了业务领域的边界。子域的划分需要结合公司自己的业务的情况,参考领域专家的意见来划分。

    2019-10-16
    1
  • 密码123456
    对于领域问题来说,可以理解为。对一个问题不断的划分,直到划分为,我们熟悉的,能够快速处理的小问题。然后在对小问题处理在排列一个优先级。

    作者回复: 赞一个,理解的非常到位。划分到最小就是聚合,聚合之上就是限界上下文,根据限界上下文建立领域模型,然后设计微服务。

    2019-10-16
    1
  •  海大
    通用域在基础设施层 理解对吗

    作者回复: 不是的,通用域也是业务域,不过是可复用的业务域。跟基础设施层是不同的纬度。

    2019-12-10
  • IT_matters
    1、领域就是问题空间的划分,子域是领域(父问题)细分的子问题。
    2、子域又可以分为核心、通用和支撑域丧类别。通用和支撑域通用性强,定制化程度低,可以适当外包。两者可以不用刻意区分。
    3、核心域是公司的战略重点,业务重点,需要重点关注。通用和支撑域如果开始赚钱,可能也会成为核心域。
    4、子域的分类主要是为了方便拼估投入的资源。

    作者回复: 是的

    2019-12-03
  • kevin
    核心域是重心,支撑域是支撑核心域的,通用域也是一种支撑域,大家都能用到而被划分到通用域
    2019-11-28
  • X中倪
    为什么说 :
    (1)《通用域》权限, 认证等等的领域可以买?
    是否可以理解为,登陆时需要短信验证码登陆。那么这个发送短信的功能就可以去买,现实上也没有自己开发。
    《核心域》主要的发展方向。淘宝的C2C ,天猫、京东、苏宁等的B2C。 公司的战略模式、发展方向、主要关注点,以什么为主。
    《支撑域》也就是说数据的结构,业务逻辑,不一样。战略、发展一样。
    总结一下:
    核心域:公司发展方向,战略等。
    通用域:发送短信,身份证实名认证等(对接第三方 直接购买)。
    支撑域:同一个行业、同一个战略、同一个发展方向。但是实现的方式不同。更直接(LOW)的说,A电商平台Go语言开发,B电商平台JAVA开发 等等等。
    2019-11-27
  • Geek_88604f
    领域划分为子域需要根据公司的业务以及依赖领域专家的知识和经验。如果领域专家的经验不足,通常需要如何应对呢?另外领域专家之间达不成一致意见,陷入无止境的争论,这种情况下有如何应对?

    作者回复: 1、领域专家经验不足就需要团队整体来讨论和决策,这个在很多新的创业的系统建设过程中应该很常见。领域模型也是需要多次迭代才能变得成熟和稳定。多做几次迭代才能摸索出完美的领域模型。
    2、这个需要团队有相应的沟通规则。

    2019-11-24
  • 山分子
    基于公司的实际情况,通用域:身份认证中心,支撑域:日志中心,核心域:业务相关的微服务。
    不知道可不可以这样划分?

    作者回复: 可以的。核心域可以考虑一下公司的战略和商业重点。

    2019-11-12
  • 宝宝太喜欢极客时间了
    领域跟子域是一个相对的概念,一个领域可能成为另外一个领域的子域,一个子域又可能成为另一个子域的领域。所以再确定领域的时候是不是得先确定好界限上下文?及确定范围呢?在一个范围内再谈领域子域。还有就是子域,到底划分到什么程度的时候就不用再划分下去,老师再文中指出要划分到聚合这里,就是说聚合就是最小的子域了吗?一个聚合对应一个微服务中的服务?

    作者回复: 我在文中讲到了,在领域不断划分的过程中,领域会被细分为不同的子域,这个过程实际上是将问题范围不断缩小的过程。借用读者“密码123456”的总结,他认为:“对于领域问题来说,可以理解为,对一个问题不断的划分,直到划分为我们熟悉的,能够快速处理的小问题。然后在对小问题处理再排列一个优先级。”这个理解是很到位的。在领域细分到一定的范围后,我们就可以对这个子域进行事件风暴,为这个子域划分限界上下文,建立领域模型,然后可以基于领域模型进行微服务设计了。

    虽然DDD没有明确说明子域和限界上下文的关系。我个人认为,子域的划分是一种比较粗的领域边界的划分,它不考虑子域内的领域对象、对象之间的关系和结构。子域的划分往往按照业务阶段或者功能模块边界进行粗分,其目的就是为了让你能够在一个相对较小的问题空间内,比较方便的用事件风暴来梳理业务场景。而限界上下文本质上也是子域,限界上下文是在明确的子域内,用事件风暴划分出来的。它体现的是一种详细的设计过程。这个过程设计出了领域模型,明确了领域对象以及领域对象的依赖等关系,有了领域模型,你就可以直接进行微服务设计了。
    聚合是最小的业务单元,也是可以独立作为微服务的。

    2019-11-03
  • 雷霹雳的爸爸
    言简意赅,概念讲述的很清楚;希望能再多一些例子,或者例子解释的更深入,特别是一些模棱两可的,或者通过例子重点讲解划分的依据和逻辑权衡的思考方式

    我觉得综合我们目前的行业因素,以及品牌价值,决定了客户服务应该是我们的核心域之一

    核心域(core domain)和通用子域(generic subdomain)好像是Eric. DDD里面有提到的,第15章精炼部分,但是这个支撑域是否来自[impl.DDD](https://book.douban.com/subject/25844633/) 中延伸出来概念?

    作者回复: 非常感谢你的建议。
    现在DDD的领域建模部分大部分还是靠领域经验,缺少可以量化的标准。

    2019-10-31
收起评论
52
返回
顶部