按子域分解模式
问题说明
微服务架构将应用程序构建为一组松散耦合的微服务,每个服务应以敏捷的方式独立开发,以实现持续交付/部署。 当使用微服务架构构建大型复杂应用时,主要问题是如何设计松耦合的微服务,或者将大型应用分解为小的松耦合服务?
解决方案
我们可以定义与领域驱动设计(DDD)子域相对应的微服务。 DDD是指业务作为一个域,一个域可以有多个子域。 现在每个子域指的是不同的区域。 例如−
订单管理 − 订单管理子域是指订单。
客户管理 − 客户管理子域指的是客户。
子域可以使用以下标准进一步分类 −
核心 − 应用程序最重要和最关键的差异化因素。
支持 − 与业务相关并用于支持业务活动。
通用 − 不特定于业务,但用于增强业务运营。
示例
考虑一个在线书店的示例。 它可以有以下子域和相应的微服务 −
图书目录管理
库存管理
订单管理
保修管理
![按子域设计模式分解](/microservices_design_patterns/images/decompose_by_subdomain.jpg)
优点
稳定的架构 − 由于业务子域稳定,所以该架构稳定性较高。
跨职能团队 − 开发团队独立工作、跨职能,并围绕功能特性而不是技术特性进行组织。
松耦合服务 − 开发的服务将是松散耦合和内聚的。
缺点
需要对业务有很好的了解 − 了解业务后,需要识别业务子域。 了解组织结构会有所帮助,因为组织是根据其能力构建的。
需要高级域模型 − 需要业务域对象,因为它们对应于业务子域。