按子域分解



问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务,每个服务都应以敏捷方式独立开发,以实现持续交付/部署。当使用微服务架构构建大型复杂应用程序时,主要问题是如何设计松散耦合的微服务,或者如何将大型应用程序分解成小型松散耦合的服务?

解决方案

我们可以根据领域驱动设计 (DDD) 的子域定义微服务。DDD 将业务视为一个领域,一个领域可以有多个子域。每个子域代表不同的领域。例如:

  • 订单管理 - 订单管理子域指的是订单。

  • 客户管理 - 客户管理子域指的是客户。

子域可以使用以下标准进一步分类:

  • 核心域 - 应用程序最重要的和关键的差异化因素。

  • 支撑域 - 与业务相关,用于支持业务活动。

  • 通用域 - 不特定于业务,但用于增强业务运营。

示例

考虑一个在线书店的例子。它可以有以下子域和相应的微服务:

  • 图书目录管理

  • 库存管理

  • 订单管理

  • 保修管理

Decompose By Subdomain Design Pattern

优点

  • 稳定的架构 - 由于业务子域是稳定的,因此该架构高度稳定。

  • 跨职能团队 - 开发团队独立工作,是跨职能的,并且围绕功能特性而不是技术特性进行组织。

  • 松散耦合的服务 - 开发的服务将是松散耦合且具有内聚性的。

缺点

  • 需要很好地理解业务 - 需要在理解业务之后才能识别业务子域。理解组织结构会有所帮助,因为组织是根据其能力构建的。

  • 需要高级别的领域模型 - 需要业务领域对象,因为它们对应于业务子域。

广告