阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/6898450822771539981 「不够具体」欢迎转载，保留摘要，谢谢！

• 什么是领域？
• 子域（Subdomain）
• 核心域（Core Domain）
  • 领域愿景说明（Domain Vision Statement）
  • 突出核心（Highlighted Core）
  • 分离的核心（Segregated Core）
• 通用子域
• 支撑子域
• 总结

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

领域和子域

在很长一段时间里，我们认为技术是主导项目成功的关键因素，这种关键因素通常表现在项目使用的编程语言、框架、架构（如：分层架构）、中间件、数据库等等方面（如：生态）。但技术真的是项目成功的关键因素吗？

在一个软件项目里除了技术层面的这部分，我们最主要的事情是实现业务。实现业务其实是在实现所在业务领域中所需要的业务。技术也是一个领域，称之为技术领域。领域驱动设计中的领域是指的业务领域。

大多数的技术人员对技术领域中的知识比较感兴趣（狂热），因为这能够使得自己在技术方面有一些前沿性和探索性的实践。然而对于业务领域中的知识就显得比较暗淡一些。

当项目的进展随着对业务领域的深入，大家又开始为各种曾经没有分析到的需求忙的焦头烂额。这个时候对技术领域的探索也基本成熟。接着又一轮新技术的出现，使得大家又开始对新技术进行探索实践，并试图使用新技术来解决掉以前遗留下来的没有解决的新需求，此时就出现了所谓的“全盘重构”。正是这种周而复始的对技术领域的不断探索，使我们对业务领域里重要地核心知识被埋没。但有一天我们认识到业务领域十分重要时，你可能已经不在这个业务领域中探索技术了。

让一个技术水平较高地技术人员去深入研究分析领域中的业务是需要勇气的，这种勇气不是来自对未知的复杂业务领域的挑战而是让自己不在无时无刻沉静在对技术探索的环境中。

这要求一些技术人员需要花费一些时间去深入到业务领域中去分析领域知识并最终形成领域模型。

问题：领域中的业务是由什么组成的呢？

回答：需求。

问题：需求又是有什么组成的呢？

什么是领域？

百度百科对领域的解释：

• 学术思想或社会活动的范围。
• 具体指一种特定的范围或区域。

《领域驱动设计》中领域指的是一个特定的业务范围，大家在这个业务域范围内开展工作。

领域这个词承载了太多的含义。在大多数人的理解中会使用领域代替行业、项目或者系统，这样会使一些人认识领域就是行业、项目或者系统。在认识领域时一定要注意所指的业务域，行业、项目或系统都不能准确地表达领域所指的业务域。

• 一个系统可能由一个领域或者多个领域组成。如果一个系统是由一个领域组成时，这会给大家一种错觉。

子域（Subdomain）

在初识子域概念时，可能会认为子域与领域的是父子关系。其实他们并不是父子关系，而是包含关系。当多个业务域（领域）的组合形成了一个更大的业务域（领域）时，其中每一个领域（业务域）是这个更大的业务域的一部分，每一个业务域相对于这个更大地业务域称之为这个更大领域的子业务域，简称子域。组合而成的这个更大地业务域统称为领域。

补充：领域与子域的关系更好的描述是饼状图，领域相当于整个饼状图，子域相当于这个饼状图中的某一个块。

这是一个有关“零售商在线销售产品”的例子，来源于《实现领域驱动设计》。

把零售商中的所有业务看做成一个领域（业务域），把这个整体业务域中的每一个业务域看做成子域。所以这个零售商业务域中包括：产品目录子域、订单子域、物流子域、发票子域、库存子域等。

这张业务域图已经为我们呈现了一个近似完整地子域划分图。那么这张图是如何完成划分的呢？

对一个业务域划分子域时，往往会把一个领域划分为：核心域、支撑子域、通用子域三种类型的子域集。其中核心域是整个业务域（领域）的核心，支撑子域和通用子域完成非核心的业务。不管怎么样，在对一个整体业务域进行划分时，首先要做的是划分核心域。

注意：三种类型的子域不是三个类型的子域，每种类型的子域数量可能有多个。

核心域（Core Domain）

核心域是整个业务系统的核心，所有的业务都要围绕着核心业务域展开。如何明确核心域呢？

通常明确核心的方式是精炼业务域。精炼是一个持续的过程，具体来说有以下几种方式：

• 领域愿景说明（Domain Vision Statement）
• 突出核心（Highlighted Core）
• 内聚机制（Cohesive Mechanism）
• 分离的核心（Segregated Core）
• 抽象核心（Abstract Core）

领域愿景说明（Domain Vision Statement）

这部分的内容在《领域驱动设计》中表达地非常简洁，没有必要再做过度的解读。具体内容如下：

并且还给出了两个“领域愿景说明”的示例：

在这两个示例中提到的模型并不是一个领域模型，而是一组领域模型。更具体地来说是要告诉我们这一组领域模型要解决什么问题，而这个要解决的问题正是由客户来提出的最需要的那个功能，这个最需要的功能正是业务域中的核心。

为业务域编写“领域愿景说明”是有必要的，因为它可以让整个团队的人员都能明确什么是核心域。正是明确了核心域，才可以使整个团队朝着统一地方向前进。

突出核心（Highlighted Core）

我们通过“领域愿景说明”可以明确什么是核心域，但这是从一个较为宽泛的角度对核心域进行说明的。我们明确核心域的目的是为了形成核心领域模型，此时我们需要突出核心。

突出核心域中的领域模型有两种方式：

• 精炼文档
• 标明核心（Core）

精炼文档要做的事情是创建一个最核心的概念对象的清单文档。

标明核心（Core） 要做的事情是从一个完整的领域模型文档中标记出最核心的领域模型。

分离的核心（Segregated Core）

分离的核心的主要目的有两个：

• 将核心域中的非核心元素（模型）分离出去。
• 将非核心域中的核心元素（模块）移动到核心域中。

这两个目的都是为了让核心域更加清晰和增强核心域的内聚性。

有关核心域的更多内容请阅读《领域驱动设计》中的第十五章，其中非常详细地阐述了如何明确核心域和实现核心域。

《实现领域驱动设计》中通过问题空间和解决方案空间对核心域做了更直接的说明：

• 问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域。[IDDD, P48]

核心域的范围并不一定是一次就能确认的，可能需要迭代很多次，每一次都有可能扩大或缩小。

通用子域

如果一个子域不是核心域并且被用于整个业务系统，那么这个子域便是通用子域。[IDDD, P44]

通用子域：模型中由你想当然的部分。不可否认，它们确实是领域模型的一部分，但它们抽象出来的概念是很多业务都需要的。比如：各个行业（如：运输业、银行业或制造业）都需要某种形式的企业组织图。[DDD, P282]

这两段摘取为我们描述出什么是通用子域，从业务域的角度来看，通用子域也是一种业务域，和核心域一样。只是没有核心域的优先级高。因为核心域是整个系统的核心，整个系统因为核心域才具有竞争性。而通用子域只是那些提供的增强功能，比如电商系统中的商品收藏、店铺收藏、用户信息等等这些功能，它们确实是电商系统中的业务，但是并不是核心业务，这些增强性的业务就是通用子域。

注意：有些小伙伴会把通用子域与共享内核混淆，是因为共享内核的组成部分既有可能是核心域、支撑子域或者通用子域。

支撑子域

在业务域中，会有一些比较重要的业务，但却不是核心，那么它便是一个支撑子域。创建支撑子域的原因在于它们专注于业务的某个方面。它不像核心域在整个系统中那么重要，也不像通用子域。

总结

在一个业务域中，基本由三种类型的子域组成，分别是：核心域、通用子域和支撑子域。在分析业务域时，首先要做的事情是分析核心域，然后设计核心域，这样就能明确系统的最主要的功能。围绕着这个核心域进行展开，慢慢添加其它子域，比如通用子域和支撑子域。在开发核心域和其它子域时，要为核心域分配最高的优先级，其它子域可以根据任务的多方面因素在分配优先级。