按子域分解 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

按子域分解

这种模式使用域驱动设计 (DDD) 子域来分解单体。这种方法将组织的域模型分解为单独的子域，这些子域被标记为核心（业务的关键差异化因素）、支持（可能与业务相关但与差异化因素无关）或通用（不是特定于业务）。这种模式适用于现有的单体系统，这些系统在子域相关模块之间具有明确定义的边界。这意味着您可以通过将现有模块重新打包为微服务来分解整体结构，而无需大量重写现有代码。每个子域都有一个模型，该模型的范围称为有界限上下文。微服务是围绕这种界限上下文开发的。下表说明了使用此模式的优势和劣势。

优点 劣势

  • 松耦合架构提供了可扩展性、弹性、可维护性、可延展性、位置透明性、协议独立性和时间独立性。

  • 系统变得更具可扩展性和可预测性。

  • 可能会创建太多的微服务，这使得服务发现和集成变得困难。

  • 业务子域很难识别，因为它们需要对整体业务有深入的了解。

下图显示了保险单体在按业务能力分解后如何将其分解为子域。

按子域分解单体

该插图显示，销售和营销服务被分解为较小的微服务。采购和索赔模型是销售的重要业务差异化因素，它们分为两个独立的微服务。通过使用活动、分析和报告等辅助业务功能来分解营销。