架构模式: 根据业务能力拆分
上下文
您正在开发一个大型，复杂的应用程序，并希望使用微服务架构。微服务架构将应用程序构建为一组松散耦合的服务。微服务架构的目标是通过实现持续交付/部署来加速软件开发。
微服务架构以两种方式实现：
- 简化测试并使组件能够独立部署
- 将工程组织构建为小型（6-10个成员）自治团队的集合，每个团队负责一个或多个服务
这些好处不会自动得到保证。相反，它们只能通过将应用程序细致地功能分解为服务来实现。
服务必须小到足以由小团队开发并且易于测试。面向对象设计（OOD）的一个有用的指导原则是单一责任原则（SRP）。SRP将类的责任定义为改变的理由，并声明类只应有一个改变的理由。将SRP应用于服务设计以及设计具有凝聚力的服务并实现一小组强相关功能是有意义的。
应用程序也以某种方式进行分解，以便大多数新的和更改的要求仅影响单个服务。这是因为影响多个服务的更改需要跨多个团队进行协调，这会降低开发速度。OOD的另一个有用原则是Common Closure Principle（CCP），它声明由于同样的原因而改变的类应该在同一个包中。例如，也许两个类实现了同一业务规则的不同方面。目标是当业务规则改变开发人员时，只需要更改少量代码（最好只有一个）的代码。在设计服务时，这种想法很有意义，因为它有助于确保每项更改只影响一项服务。
问题
如何将应用程序分解为服务？
需求
- 架构必须稳定服务必须具有凝聚力。
- 服务应该实现一小组强相关的功能。
- 服务必须符合通用关闭原则
- 一起更改的内容应该打包在一起， 以确保每个更改只影响一个服务服务必须松散耦合
- 每个服务作为封装其实现的API。可以在不影响客户端的情况下更改实现
- 服务应该是可测试的每个服务都小到可以由“两个比萨”团队开发，即一个6-10人的团队。拥有一个或多个服务的每个团队必须是自治的。
- 团队必须能够与其他团队进行最少的协作来开发和部署他们的服务。
方案
定义与业务功能相对应的服务
相关的模式
- 子域模式分解是一种替代模式