02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？
该思维导图由 AI 生成，仅供参考
如何理解领域和子域？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
领域驱动设计（DDD）中的核心概念包括领域、子域、核心域、通用域和支撑域。本文通过自然科学研究方法的类比，解释了领域如何通过细分为子域来降低研究的复杂度。以保险行业为例，说明了如何根据业务关联度和流程边界将保险领域细分为不同的子域，并建立相应的领域模型和微服务。核心域、通用域和支撑域的划分有助于公司对不同子域采取不同的资源投入和建设策略。在微服务架构转型中，建议将核心域的建设排在首位，重点关注核心域的掌控和自主研发能力。通过领域划分，公司可以更好地理解业务领域，降低系统实现的复杂度，构建合适的领域模型，从而实现微服务化。读者可以结合所在公司的业务情况，尝试给业务做一个领域拆分，找出核心域、通用域和支撑域，以制定相应的资源投入和建设策略。
《DDD 实战课》，新⼈⾸单¥59
全部留言(127)
- 最新
- 精选
祥敏您好，以我公司新启动的业务线“平安社区”为例，以安防设备为集成基础。安防设备和物联网平台却都是市场成熟厂家提供，划分为通用域；平安社区业务场景如人车双验、异常人员识别等个性化应用属于业务线的支撑域；人员数据、行为数据富有长期价值，这些视为核心域。如果未来在某个细分场景做到了领先且拥有市场壁垒，这样的业务也可能会从支撑域调整为核心域。 所以，核心域、通用域、支撑域的划分本质是公司战略方向的体现，DDD是从战略到战术角度来进行架构设计的方法。作者回复: 是这样的。
2019-10-294106
stg609老师你好，关于问题空间和解决方案空间一直不是很理解，子域的划分属于问题空间，而限界上下文则属于解决方案空间。 但是这个所谓的问题空间和解决方案空间到底是啥？对于我们分析问题而言为何要划分这两种空间？作者回复: 你可以这么理解。问题空间的划分也就是子域的划分过程，实际上还是一个业务粗分过程，因为领域太大的话，你不方便对它进行分析和设计。 只有问题空间小到一定程度后，你才可以熟悉的定义解决方案空间，在这个比较小的空间内进行事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型，再进行微服务的设计，也就是一个解决方案的形成过程。
2019-10-2244
密码123456对于领域问题来说，可以理解为。对一个问题不断的划分，直到划分为，我们熟悉的，能够快速处理的小问题。然后在对小问题处理在排列一个优先级。作者回复: 赞一个，理解的非常到位。划分到最小就是聚合，聚合之上就是限界上下文，根据限界上下文建立领域模型，然后设计微服务。
2019-10-1626
桂爸通用域在基础设施层 理解对吗作者回复: 不是的，通用域也是业务域，不过是可复用的业务域。跟基础设施层是不同的纬度。
2019-12-1025
vivi通用域和支撑域对应到企业系统是哪些呢？作者回复: 通用域是一些大家都需要用的通用系统，比如认证，权限等等，这类应用很容易买到，不需要做太多的定制化，没有企业特点。支撑域具有企业特性，但不具有通用性，比如数据代码类的数据字典等系统。
2019-10-16225
Catwell13年以前基本是三层架构开发，13年后开始使用DDD，没系统的研究过，只是看了一些资料，我的理解是基于业务的属性，把原先的三层变成N个三层，相互间用接口或者API传输，不知道我这样理解对不对。作者回复: DDD包括战略和战术设计两个部分，战略设计完成领域建模，战术设计完成微服务设计。您说的应该属于战术设计的部分，DDD分层架构包括用户接入层、应用层、领域层和基础层四层，每层有不同的服务，职责不同。后面章节有详细介绍，请耐心等待。
2019-10-16320
Geek_a91670有些领域边界特别模糊,不好划分,例如:某些子领域两边都靠,不知道怎么取舍作者回复: 看领域大小，不大的话可以考虑放在一个限界上下文内，做成一个微服务。比较大的话，可先做好聚合的边界，以后随时可以根据需要来拆分微服务。
2019-10-1817- 宝宝太喜欢极客时间了领域跟子域是一个相对的概念，一个领域可能成为另外一个领域的子域，一个子域又可能成为另一个子域的领域。所以再确定领域的时候是不是得先确定好界限上下文？及确定范围呢？在一个范围内再谈领域子域。还有就是子域，到底划分到什么程度的时候就不用再划分下去，老师再文中指出要划分到聚合这里，就是说聚合就是最小的子域了吗？一个聚合对应一个微服务中的服务？
作者回复: 我在文中讲到了，在领域不断划分的过程中，领域会被细分为不同的子域，这个过程实际上是将问题范围不断缩小的过程。借用读者“密码123456”的总结，他认为：“对于领域问题来说，可以理解为，对一个问题不断的划分，直到划分为我们熟悉的，能够快速处理的小问题。然后在对小问题处理再排列一个优先级。”这个理解是很到位的。在领域细分到一定的范围后，我们就可以对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，然后可以基于领域模型进行微服务设计了。 虽然DDD没有明确说明子域和限界上下文的关系。我个人认为，子域的划分是一种比较粗的领域边界的划分，它不考虑子域内的领域对象、对象之间的关系和结构。子域的划分往往按照业务阶段或者功能模块边界进行粗分，其目的就是为了让你能够在一个相对较小的问题空间内，比较方便的用事件风暴来梳理业务场景。而限界上下文本质上也是子域，限界上下文是在明确的子域内，用事件风暴划分出来的。它体现的是一种详细的设计过程。这个过程设计出了领域模型，明确了领域对象以及领域对象的依赖等关系，有了领域模型，你就可以直接进行微服务设计了。 聚合是最小的业务单元，也是可以独立作为微服务的。
2019-11-0315 - Geek_e8f4b0发现文章有点晚最近才看到，很有启发，tks，我有一个疑问：一个子域是不是等于一个限界上下文边界，如果不是，那么如何划分子域，子域与限界上下文又是什么关系，因为你后续相关文章都是提高由事情找实体和值对象，根据实体和值对象找聚合根形成聚合，聚合s+限界上下文+一些微服务的拆分原则构成一个微服务。那子域在其中并没有启动拆分的作用。
作者回复: 最近在准备书的内容，书里面对这一部有详细说明，我就直接复制过来了。 在DDD中包括问题域和解决方案域两个不同的维度。问题域主要从业务视角来考虑，完成从领域到子域的分解，而解决方案域则主要从技术实现的角度，通过划分限界上下文和采用DDD战术设计完成微服务拆分和落地。“子域”和“限界上下文”这两个概念分别从不同的视角，构建起了DDD 处理业务复杂度的根基。 个人认为“子域”和“限界上下文”在大多数情况下是一对一或者一对多的映射关系。从实践角度，我们可以这样理解，我们不妨将业务领域的分解拆分为两个阶段：从领域到子域的粗粒度的分解和从子域到限界上下文的技术实现级的分解。有时候企业的业务领域非常庞大，不太方便用事件风暴对整个领域构建领域模型。所以在领域建模之前，我们先根据业务流程边界或者功能集合等要素，将庞大的领域分解成若干个大小合适的子域，然后根据子域属性划分为核心子域、通用子域和支撑子域。当领域分解到足够小后，我们就可以在这些子域内开展事件风暴，划分限界上下文完成领域建模。 在对不同属性子域构建领域模型时，我们可能会有不同的关注点，比如在通用子域构建领域模型时，我们会更多的关注领域模型的抽象和标准化，以便实现企业级复用，这种设计方法与中台的业务建模方法是一致的。当然，如果你的领域足够小的话，我们就没必要进行从领域到子域的分解和属性归类了，你可以直接开展事件风暴，直接划分限界上下文，完成领域建模。按照这种分解方式，如果子域和限界上下文边界刚好一致，那它们就是一对一的关系，而如果在一个子域内还可以划分为多个限界上下文，那我们最终得到的就是一对多的映射关系。需要注意的是，有些通用子域构建出来的领域模型往往会因为复用的需要，可能会跨多个不同的其他业务子域。 限界上下文本质上就是子域，只不过它会更多的考虑领域对象的语义边界和技术实现细节。限界上下文的划分体现的是一种更为详细的设计过程，这个过程划分了业务的上下文语义边界，完成了领域模型，明确了领域对象以及领域对象之间的依赖关系等。我们依据限界上下文和领域模型就可以完成微服务设计和落地了。
2020-06-1814 
拙言这里没看限界上下文的概念，在桃树的例子中，细胞即为限界的上下文吗？还是说，器官，组织，细胞都是限界的上下文？作者回复: 你好，段拙言。还是你细心，不过不要纠结这里的限界上下文的概念，限界上下文是由它的语义边界来确定的。在DDD里面一个聚合可以是一个限界上下文，多个不同职能的聚合也可以组成为一个限界上下文，他们都在一个语义环境下。有的组织可能只有单一细胞，有的组织可能由多个不同功能的细胞组成的。我们重温一下生物课哈。由一种细胞所构成的均一组织。而由两种以上细胞构成的不均一的组织称为复合组织。特定功能（特定的语义环境）的组织基本上就可以对应到限界上下文。
2019-10-16313
