REL03-BP02 构建专注于特定业务领域和功能的服务
服务导向型架构(SOA)采用按业务需求定义的、划分明确的功能来定义服务。微服务使用域模型和限界上下文,沿业务环境边界划定服务边界。通过将重点放在业务领域和功能上,有助于团队为其服务定义独立的可靠性要求。限界上下文隔离和封装业务逻辑,让团队能够更好地解释如何处理故障。
期望的结果: 工程师和业务利益相关者共同定义限界上下文,并使用它们将系统设计为实现特定业务功能的服务。这些团队使用事件风暴等既定的实践来定义需求。新的应用程序被设计为服务,具有明确定义的边界并采用松耦合。现有的整体式架构被分解为 限界上下文
面向领域的服务作为一个或多个进程执行,彼此之间不分享状态。这些进程独立应对需求的波动,并根据特定领域的要求处理故障情景。
常见反模式:
-
围绕特定技术领域(例如 UI 和 UX、中间件或数据库)组建团队,而不是根据特定的业务领域组建。
-
应用程序进行了领域职责划分。跨越限界上下文的服务可能更难于维护,需要更多测试工作,并且需要多个领域团队参与软件更新。
-
领域依赖关系(例如领域实体库)在服务之间共享,因此对一个服务领域进行更改也需要更改其他服务领域
-
服务合同和业务逻辑没有使用通用且一致的领域语言来描述实体,这会导致翻译层的存在,使得系统更加复杂并增加调试工作量。
建立此最佳实践的好处: 应用程序被设计为独立的服务,按照业务领域确定界限,并使用通用的业务语言。服务可独立测试和部署。对于所实施的领域,服务满足特定于领域的弹性要求。
未建立这种最佳实践的情况下暴露的风险等级: 高
实施指导
领域驱动型决策(DDD)是围绕业务领域设计和构建软件的基本方法。围绕业务领域构建服务时,使用现有框架会很有帮助。在使用现有的整体式应用程序时,您可以利用分解模式提供成熟的技术,将应用程序现代化改造为服务。
![描述领域驱动型决策方法的流程图。](images/domain-driven-decision.png)
领域驱动型决策
实施步骤
-
团队可以举办 事件风暴
研讨会,以简便的便签格式,快速确定事件、命令、聚合和领域。 -
在领域上下文中构建领域实体和功能后,您可以使用 限界上下文
将领域划分为服务,具有相似功能和属性的实体分组在一起。通过将模型细分为不同的上下文,即可得到如何确定微服务边界的模板。 -
以 Amazon.com 网站为例,实体可能包括包装、配送、时间表、价格、折扣和货币。
-
包装、配送和时间表分组到运输上下文中,而价格、折扣和货币分组到定价上下文中。
-
-
将整体式架构分解为微服务 概述了重构微服务的模式。使用按照业务功能、子领域或事务进行分解的模式,与领域驱动型方法非常吻合。
-
利用 气泡上下文
等战术性技巧,您可以在现有或旧版应用程序中引入 DDD,无需预先重新编写和承诺完全转向 DDD。在气泡上下文方法中,使用服务映射和协调来建立小型限界上下文,或者建立 防护层 ,该层保护新定义的领域模型免受外部影响。
在团队进行了领域分析并定义实体和服务合同后,他们可以利用 AWS 服务,将自己的领域驱动型设计作为云端服务来实施。
-
通过定义执行领域业务规则的测试来开始开发。测试驱动型开发(TDD)和行为驱动型开发(BDD),有助于团队将服务重点放在解决业务问题上。
-
在 AWS 上构建六边形架构 中概述了一个框架,从业务领域出发,采用逆向工作方法,将业务逻辑构建到服务中,以满足功能需求,然后连接集成适配器。采用将接口详细信息从业务逻辑与 AWS 服务之间分离的模式,让团队能够专注于研究领域功能并提高软件质量。
资源
相关最佳实践:
相关文档:
相关示例:
相关工具: