模式：按子域分解

原文地址http://microservices.io/patterns/decomposition/decompose-by-subdomain.html

上下文

您正在开发一个庞大而复杂的应用程序，并希望使用微服务架构。微服务架构将应用程序构造为一组松散耦合的服务。微服务架构的目标是通过实现持续的交付/部署来加速软件开发。

微服务架构有两种方式：

1.简化测试并使组件能够独立部署

2.将工程组织结构化为小型（6-10名成员）的团队，自主团队，每个团队负责一个或多个服务

这些好处不能自动保证。相反，它们只能通过将应用程序细致的功能分解成服务来实现。

服务必须足够小，由小团队开发，并且易于测试。面向对象设计（OOD）中一条有用指导是单一责任原则（SRP）。SRP定义了一个类的责任（responsibility）作为可变的理由，并声明一个类只应该有一个理由来改变。将SRP应用于服务设计以及设计高内聚的服务、并实现一个小的强相关的功能集是有意义的。

应用程序以某种方式进行分解，以便大多数新的和变更的需求仅影响单个服务。因为影响多个服务的变化需要跨多个团队进行协调，这会减慢开发速度。来自OOD的另一个有用的原则是通用关闭原则（CCP），其中指出，由于相同原因而改变的类应该在同一个包中。也许，例如，两个类实现相同业务规则的不同方面。目标是当业务规则改变时，开发人员只需要更改一小部分代码（理想情况下只需一个）。在设计服务时，这种思维是有意义的，因为它将有助于确保每个更改只会影响一项服务。

问题

如何将应用程序分解为服务？

目标

• 架构必须稳定
• 服务必须高内聚。一个服务应该实现一个小的强相关功能的集合。
• 服务必须符合通用关闭原则 - 一起变化的事项应该打包在一起，以确保每个更改仅影响一个服务
• 服务必须松散耦合 - 每个服务作为封装其实现的API。可以在不影响客户端的情况下更改实现
• 服务应该是可测试的
• 每个服务都足够小，由“两个比萨”团队开发，即一个6-10人的团队
• 拥有一个或多个服务的每个团队必须是自主的。一个团队必须能够通过与其他团队的最小协作来开发和部署他们的服务。

方案

定义与Domain-Driven设计（DDD）子域相对应的服务。DDD是指应用程序的问题空间 -业务 - 作为域。域由多个子域组成。每个子域对应于业务的不同部分。

子域可以分类如下：

•核心 -业务关键差异化和应用程序中最有价值的部分

•支持 -与业务有关，而不是差异化。这些可以在内部实施或外包。

•通用 -不是特定于业务的，理想地使用现成的软件实现

示例

在线商店的子域包括：

•    产品目录

•    库存管理

•    订单管理

•     交货管理

•...

相应的微服务架构将具有与这些子域对应的服务。