DDD 实战课
欧创新
人保资深架构师
55517 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 26 讲
开篇词 (1讲)
DDD 实战课
15
15
1.0x
00:00/00:00
登录|注册

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

不同的资源投入和建设策略
区分不同子域的功能属性和重要性
降低业务理解和系统实现的复杂度
逐级细分问题域
公司战略重点和商业模式的结合
有限资源下的关注度和资源投入策略
具有企业特性
不包含通用功能
不包含核心竞争力功能
没有个性化诉求
被多个子域使用的通用功能子域
业务成功的主要因素
决定产品和公司核心竞争力的子域
建立完整知识体系
逐步细分问题域
对应更小的问题域或业务范围
划分出的多个子领域
业务问题域的解决
边界的重要性
用于确定范围
尝试给业务做一个领域拆分
核心域、支撑域和通用域的主要目标
领域的核心思想
划分目的
支撑域
通用域
核心域
业务领域的细分和微服务的建设过程
DDD的研究方法与自然科学的研究方法类似
子域
领域
思考题
总结
如何理解核心域、通用域和支撑域?
如何理解领域和子域?
领域、子域、核心域、通用域和支撑域

该思维导图由 AI 生成,仅供参考

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

如何理解领域和子域?

我们先看一下汉语词典中对领域的解释:“领域是从事一种专门活动或事业的范围、部类或部门。”百度百科对领域的解释:“领域具体指一种特定的范围或区域。”
两个解释有一个共同点——范围。对了!领域就是用来确定范围的,范围即边界,这也是 DDD 在设计中不断强调边界的原因。
在研究和解决业务问题时,DDD 会按照一定的规则将业务领域进行细分,当领域细分到一定的程度后,DDD 会将问题范围限定在特定的边界内,在这个边界内建立领域模型,进而用代码实现该领域模型,解决相应的业务问题。简言之,DDD 的领域就是这个边界内要解决的业务问题域。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

领域驱动设计(DDD)中的核心概念包括领域、子域、核心域、通用域和支撑域。本文通过自然科学研究方法的类比,解释了领域如何通过细分为子域来降低研究的复杂度。以保险行业为例,说明了如何根据业务关联度和流程边界将保险领域细分为不同的子域,并建立相应的领域模型和微服务。核心域、通用域和支撑域的划分有助于公司对不同子域采取不同的资源投入和建设策略。在微服务架构转型中,建议将核心域的建设排在首位,重点关注核心域的掌控和自主研发能力。通过领域划分,公司可以更好地理解业务领域,降低系统实现的复杂度,构建合适的领域模型,从而实现微服务化。读者可以结合所在公司的业务情况,尝试给业务做一个领域拆分,找出核心域、通用域和支撑域,以制定相应的资源投入和建设策略。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DDD 实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(127)

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

    作者回复: 是这样的。

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

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

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

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

    2019-10-16
    26
  • 桂爸
    通用域在基础设施层 理解对吗

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

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

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

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

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

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

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

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

    作者回复: 我在文中讲到了,在领域不断划分的过程中,领域会被细分为不同的子域,这个过程实际上是将问题范围不断缩小的过程。借用读者“密码123456”的总结,他认为:“对于领域问题来说,可以理解为,对一个问题不断的划分,直到划分为我们熟悉的,能够快速处理的小问题。然后在对小问题处理再排列一个优先级。”这个理解是很到位的。在领域细分到一定的范围后,我们就可以对这个子域进行事件风暴,为这个子域划分限界上下文,建立领域模型,然后可以基于领域模型进行微服务设计了。 虽然DDD没有明确说明子域和限界上下文的关系。我个人认为,子域的划分是一种比较粗的领域边界的划分,它不考虑子域内的领域对象、对象之间的关系和结构。子域的划分往往按照业务阶段或者功能模块边界进行粗分,其目的就是为了让你能够在一个相对较小的问题空间内,比较方便的用事件风暴来梳理业务场景。而限界上下文本质上也是子域,限界上下文是在明确的子域内,用事件风暴划分出来的。它体现的是一种详细的设计过程。这个过程设计出了领域模型,明确了领域对象以及领域对象的依赖等关系,有了领域模型,你就可以直接进行微服务设计了。 聚合是最小的业务单元,也是可以独立作为微服务的。

    2019-11-03
    15
  • Geek_e8f4b0
    发现文章有点晚最近才看到,很有启发,tks,我有一个疑问:一个子域是不是等于一个限界上下文边界,如果不是,那么如何划分子域,子域与限界上下文又是什么关系,因为你后续相关文章都是提高由事情找实体和值对象,根据实体和值对象找聚合根形成聚合,聚合s+限界上下文+一些微服务的拆分原则构成一个微服务。那子域在其中并没有启动拆分的作用。

    作者回复: 最近在准备书的内容,书里面对这一部有详细说明,我就直接复制过来了。 在DDD中包括问题域和解决方案域两个不同的维度。问题域主要从业务视角来考虑,完成从领域到子域的分解,而解决方案域则主要从技术实现的角度,通过划分限界上下文和采用DDD战术设计完成微服务拆分和落地。“子域”和“限界上下文”这两个概念分别从不同的视角,构建起了DDD 处理业务复杂度的根基。 个人认为“子域”和“限界上下文”在大多数情况下是一对一或者一对多的映射关系。从实践角度,我们可以这样理解,我们不妨将业务领域的分解拆分为两个阶段:从领域到子域的粗粒度的分解和从子域到限界上下文的技术实现级的分解。有时候企业的业务领域非常庞大,不太方便用事件风暴对整个领域构建领域模型。所以在领域建模之前,我们先根据业务流程边界或者功能集合等要素,将庞大的领域分解成若干个大小合适的子域,然后根据子域属性划分为核心子域、通用子域和支撑子域。当领域分解到足够小后,我们就可以在这些子域内开展事件风暴,划分限界上下文完成领域建模。 在对不同属性子域构建领域模型时,我们可能会有不同的关注点,比如在通用子域构建领域模型时,我们会更多的关注领域模型的抽象和标准化,以便实现企业级复用,这种设计方法与中台的业务建模方法是一致的。当然,如果你的领域足够小的话,我们就没必要进行从领域到子域的分解和属性归类了,你可以直接开展事件风暴,直接划分限界上下文,完成领域建模。按照这种分解方式,如果子域和限界上下文边界刚好一致,那它们就是一对一的关系,而如果在一个子域内还可以划分为多个限界上下文,那我们最终得到的就是一对多的映射关系。需要注意的是,有些通用子域构建出来的领域模型往往会因为复用的需要,可能会跨多个不同的其他业务子域。 限界上下文本质上就是子域,只不过它会更多的考虑领域对象的语义边界和技术实现细节。限界上下文的划分体现的是一种更为详细的设计过程,这个过程划分了业务的上下文语义边界,完成了领域模型,明确了领域对象以及领域对象之间的依赖关系等。我们依据限界上下文和领域模型就可以完成微服务设计和落地了。

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

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

    2019-10-16
    3
    13
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部