DDD之领域（Domain）和子域（Subdomain）

领域驱动设计系列文章，点击上方合集↑

1. 领域

领域（Domain）是一个组织所做的事情以及其中所包含的一切，领域可以表示整个业务系统。

领域，简单来说，是指一个业务或行业领域，例如电商、社交媒体、金融等。在软件开发中，将领域抽象出来，以便更好地理解业务需求，并将其作为设计和实现的核心。领域由一组相关的业务概念、规则、流程和行为组成，它们共同构成了业务领域的核心要素。通过理解和建模领域，我们可以更好地设计出与实际业务需求相符合的软件系统。

2. 子域

在DDD中，一个领域被分为若干子域，领域模型在限界上下文中完成开发。

子域（Subdomain）是领域的一部分，它代表了领域中的一个较小的特定业务领域。在一个大型复杂的领域中，可以将其拆分为多个子域来进行设计和开发。子域通常具有自己独特的业务概念、规则和流程，而且往往有着较高的内聚性，因此可以将其当作一个相对独立的业务模块进行开发。每个子域都有自己的上下文和职责，可以由一个团队或多个团队来负责。

一个简单的电商的例子：

商家向买家展示不同类别的产品，允许买家下单和付款，还需要安排物流。在这个领域中，零售商的领域可以分为4个主要的子域：产品目录（ProductCatalog）、订单（Order）、发票（Invoicing）和物流（Shipping）。

如上我们还加入一个库存（Inventory）系统，还有地图系统支撑子域、算法推荐支撑子域，日志和监控通用子域，认证和授权通用子域。

• 核心域（Sub Domain）：它是一个唯一的、定义明确的领域模型，要对它进行战略投资，并在一个明确的限界上下文中投入大量资源去精心打磨通用语言。它是组织中最重要的项目，因为这将是你与其他竞争者的区别所在。正是因为你的组织无法在所有领域都出类拔萃，所以必须把核心域打造成组织的核心竞争力。做出这样的决定需要对核心域进行深入的学习与理解，而这需要承诺、协作与试验。这是组织最需要在软件中倾斜投资的方向。

• 支撑子域（Supporting Subdomain）：这类建模场景提倡的是“定制开发”，因为找不到现成的解决方案。对它的投入无论如何也达不到与核心域相同的程度。也许会考虑使用外包的方式实现此类限界上下文，以避免因错误地认为其具有战略意义而进行巨额的投资。这类软件模型仍旧非常重要，核心域的成功离不开它。

• 通用子域（Generic Subdomain）：通用子域的解决方案可以采购现成的，也可以采用外包的方式，抑或是由内部团队实现，但我们不用为其分配与核心域同样优质的研发资源，甚至都不如支撑子域。

3. 子域与微服务

子域在领域驱动设计中是对业务领域的逻辑划分，而微服务是一种实现架构上的解决方案，将系统拆分为独立的服务。子域可以指导微服务的划分，并帮助实现系统的松耦合、可扩展的微服务架构。

具体来说，每个子域可以作为一个微服务的边界，该微服务负责实现子域的业务逻辑。每个微服务可以独立开发、部署和扩展，通过接口和交互来实现子域之间的通信和协作（上下文映射）。

上述的电商系统我们就可以创建类似如下的多模块项目：

• 商品服务（Product Service）
• 订单服务（Order Service）
• 发票服务（Invoicing Service）
• 物流服务（Shipping Service）
• 库存服务（Inventory Service）
• 地图服务（Map Service）
• 推荐服务（Recommendation Service）
• 日志服务（Logging Service）
• 监控服务（Monitoring Service）
• 认证服务（Authentication Service）
• 授权服务（Authorization Service）
• …

4. 最后

虽然很多开发人员没有专门学习过领域驱动设计（DDD）,但是实际上创建项目也是按照上述这么创建的（多模块），实际上我们在开发中应用了领域驱动设计的思想，因为我们使用的微服务架构本质上就是符合领域驱动设计的理念来构建系统。

需要指出的是，微服务架构概念是由Martin Fowler与James Lewis于2014年提出的，而领域驱动设计则早在2004年就由Eric Evans提出。领域驱动设计比微服务架构早了整整10年。在当时，JSP和单体应用架构是主流，但Eric Evans就思考并提出了领域驱动设计的概念。

---

关注微信公众号：“小虎哥的技术博客”，让我们一起成为更优秀的程序员❤️！