# REL03-BP02 构建专注于特定业务领域和功能的服务
<a name="rel_service_architecture_business_domains"></a>

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

 **期望结果：**工程师和业务利益相关方共同定义限界上下文，并使用它们将系统设计为实现特定业务功能的服务。这些团队使用事件风暴等既定的实践来定义需求。新的应用程序被设计为服务，具有明确定义的边界并采用松耦合。现有整体式架构被分解为[限界上下文](https://martinfowler.com/bliki/BoundedContext.html)，而系统设计则朝着服务导向型架构或微服务架构转变。重构整体式架构时，会应用气泡上下文和整体式架构分解模式等既定方法。

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

 **常见反模式：**
+  围绕特定技术领域（例如 UI 和 UX、中间件或数据库）组建团队，而不是根据特定的业务领域组建。
+  应用程序进行了领域职责划分。跨越限界上下文的服务可能更难于维护，需要更多测试工作，并且需要多个领域团队参与软件更新。
+  领域依赖关系（例如领域实体库）在服务之间共享，因此对一个服务领域进行更改也需要更改其他服务领域 
+  服务合同和业务逻辑没有使用通用且一致的领域语言来描述实体，这会导致翻译层的存在，使得系统更加复杂并增加调试工作量。

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

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

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

![\[描述领域驱动型设计方法的流程图。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)


 

## 实施步骤
<a name="implementation-steps"></a>
+  团队可以举办[事件风暴](https://serverlessland.com/event-driven-architecture/visuals/event-storming)讲习会，以简便的便签格式，快速确定事件、命令、聚合和领域。
+  在领域上下文中形成领域实体和功能后，您可以使用[限界上下文](https://martinfowler.com/bliki/BoundedContext.html)将领域划分为服务，将具有相似特征和属性的实体分成一组。通过将模型细分为不同的上下文，即可得到如何确定微服务边界的模板。
  +  以 Amazon.com 网站为例，实体可能包括包装、配送、时间表、价格、折扣和货币。
  +  包装、配送和时间表分组到运输上下文中，而价格、折扣和货币分组到定价上下文中。
+  [Decomposing monoliths into microservices](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) 概述了重构微服务的模式。使用按照业务功能、子领域或事务进行分解的模式，与领域驱动型方法非常吻合。
+  利用[气泡上下文](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)等战术性技巧，您可以在现有或旧版应用程序中引入 DDD，无需预先重新编写和承诺完全转向 DDD。在气泡上下文方法中，使用服务映射和协调来建立小型限界上下文，或建立[防损层](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)来保护新定义的领域模型免受外部影响。

 在团队进行了领域分析并定义实体和服务合同后，他们可以利用 AWS 服务，将自己的领域驱动型设计作为云端服务来实施。
+  通过定义执行领域业务规则的测试来开始开发。测试驱动型开发（TDD）和行为驱动型开发（BDD），有助于团队将服务重点放在解决业务问题上。
+  选择最符合业务领域要求和[微服务架构](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)的 [AWS 服务](https://aws.amazon.com/microservices/)：
  +  [AWS 上的无服务器](https://aws.amazon.com/serverless/)服务让团队可以将精力集中于具体的领域逻辑上，而不是管理服务器和基础设施。
  +  [AWS 上的容器](https://aws.amazon.com/containers/)可简化基础设施的管理，让您可以将精力集中于领域要求上。
  +  [专用数据库](https://aws.amazon.com/products/databases/)有助于将领域要求与最适合的数据库类型相匹配。
+  [Building hexagonal architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) 中概述了一个框架，即从业务领域出发，采用逆向工作方法，将业务逻辑构建到服务中来满足功能要求，然后连接集成适配器。采用将接口详细信息从业务逻辑与 AWS 服务之间分离的模式，让团队能够专注于研究领域功能并提高软件质量。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL03-BP01 选择如何划分工作负载](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP03 根据 API 提供服务合同](rel_service_architecture_api_contracts.md) 

 **相关文档：**
+ [AWS 微服务](https://aws.amazon.com/microservices/)
+  [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [How to break a Monolith into Microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [Getting Started with DDD when Surrounded by Legacy Systems](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+ [Domain-Driven Design: Tackling Complexity in the Heart of Software](https://www.amazon.com/gp/product/0321125215)
+ [Building hexagonal architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [Decomposing monoliths into microservices](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [Messages Between Bounded Contexts](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [Microservices](https://www.martinfowler.com/articles/microservices.html)
+ [Test-driven development](https://en.wikipedia.org/wiki/Test-driven_development)
+ [Behavior-driven development](https://en.wikipedia.org/wiki/Behavior-driven_development)

 **相关示例：**
+ [Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop)](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)

 **相关工具：**
+ [AWS 云 数据库](https://aws.amazon.com/products/databases/)
+ [AWS 上的无服务器](https://aws.amazon.com/serverless/)
+ [AWS 上的容器](https://aws.amazon.com/containers/)