REL03-BP02 构建专注于特定业务领域和功能的服务 - AWS Well-Architected Framework

REL03-BP02 构建专注于特定业务领域和功能的服务

服务导向型架构(SOA)采用按业务需求定义的、划分明确的功能来定义服务。微服务使用域模型和限界上下文,沿业务环境边界划定服务边界。通过将重点放在业务领域和功能上,有助于团队为其服务定义独立的可靠性要求。限界上下文隔离和封装业务逻辑,让团队能够更好地解释如何处理故障。

期望的结果: 工程师和业务利益相关者共同定义限界上下文,并使用它们将系统设计为实现特定业务功能的服务。这些团队使用事件风暴等既定的实践来定义需求。新的应用程序被设计为服务,具有明确定义的边界并采用松耦合。现有的整体式架构被分解为 限界上下文 ,而系统设计转向 SOA 或微服务架构。重构整体式架构时,会应用气泡上下文和整体式架构分解模式等既定方法。

面向领域的服务作为一个或多个进程执行,彼此之间不分享状态。这些进程独立应对需求的波动,并根据特定领域的要求处理故障情景。

常见反模式:

  • 围绕特定技术领域(例如 UI 和 UX、中间件或数据库)组建团队,而不是根据特定的业务领域组建。

  • 应用程序进行了领域职责划分。跨越限界上下文的服务可能更难于维护,需要更多测试工作,并且需要多个领域团队参与软件更新。

  • 领域依赖关系(例如领域实体库)在服务之间共享,因此对一个服务领域进行更改也需要更改其他服务领域

  • 服务合同和业务逻辑没有使用通用且一致的领域语言来描述实体,这会导致翻译层的存在,使得系统更加复杂并增加调试工作量。

建立此最佳实践的好处: 应用程序被设计为独立的服务,按照业务领域确定界限,并使用通用的业务语言。服务可独立测试和部署。对于所实施的领域,服务满足特定于领域的弹性要求。

未建立这种最佳实践的情况下暴露的风险等级:

实施指导

领域驱动型决策(DDD)是围绕业务领域设计和构建软件的基本方法。围绕业务领域构建服务时,使用现有框架会很有帮助。在使用现有的整体式应用程序时,您可以利用分解模式提供成熟的技术,将应用程序现代化改造为服务。

描述领域驱动型决策方法的流程图。

领域驱动型决策

实施步骤

  • 团队可以举办 事件风暴 研讨会,以简便的便签格式,快速确定事件、命令、聚合和领域。

  • 在领域上下文中构建领域实体和功能后,您可以使用 限界上下文将领域划分为服务,具有相似功能和属性的实体分组在一起。通过将模型细分为不同的上下文,即可得到如何确定微服务边界的模板。

    • 以 Amazon.com 网站为例,实体可能包括包装、配送、时间表、价格、折扣和货币。

    • 包装、配送和时间表分组到运输上下文中,而价格、折扣和货币分组到定价上下文中。

  • 将整体式架构分解为微服务 概述了重构微服务的模式。使用按照业务功能、子领域或事务进行分解的模式,与领域驱动型方法非常吻合。

  • 利用 气泡上下文 等战术性技巧,您可以在现有或旧版应用程序中引入 DDD,无需预先重新编写和承诺完全转向 DDD。在气泡上下文方法中,使用服务映射和协调来建立小型限界上下文,或者建立 防护层,该层保护新定义的领域模型免受外部影响。

在团队进行了领域分析并定义实体和服务合同后,他们可以利用 AWS 服务,将自己的领域驱动型设计作为云端服务来实施。

  • 通过定义执行领域业务规则的测试来开始开发。测试驱动型开发(TDD)和行为驱动型开发(BDD),有助于团队将服务重点放在解决业务问题上。

  • 选择最能满足您的业务领域要求的 AWS 服务 以及 微服务架构

    • AWS 无服务器 让您的团队可以将精力集中于具体的领域逻辑上,而不是管理服务器和基础设施。

    • AWS 上的容器 可简化基础设施的管理,这样您便可以将精力集中于领域需求方面。

    • 专用数据库 有助于您将领域需求与最适合的数据库类型相匹配。

  • 在 AWS 上构建六边形架构 中概述了一个框架,从业务领域出发,采用逆向工作方法,将业务逻辑构建到服务中,以满足功能需求,然后连接集成适配器。采用将接口详细信息从业务逻辑与 AWS 服务之间分离的模式,让团队能够专注于研究领域功能并提高软件质量。

资源

相关最佳实践:

相关文档:

相关示例:

相关工具: