拆分：按子域

背景

你正在开发一个大型，复杂的应用程序，并且使用微服务架构。微服务架构将应用程序组织为松散耦合的一组服务。微服务架构的目标是通过启用持续交付/部署提高开发速度。

image
微服务架构通过以下两种方式做到这点：

1. 简单化测试，并且允许组件独立部署
2. 将工程师组织为小的（6 - 10个成员），自动化的团队，每个团队负责一个或多个服务

这些优点不是自动保证的。相反，他们只有小心的将应用功能拆分成服务才能达到。

一个服务必须足够小，以给小型团队开发和容易测试。一个从面向对象设计（OOD）而来的有用的指导，是单一职责原理（SRP）。SRP将类的职责定义为变化的原因，同时指出一个类有且只有一个原因发生改变。将SRP应用到服务设计，同时将服务设计为实现了一组强关联的功能的结合，是非常有意义的。

应用通常采用一种方式拆分，这样多数新需求，和需求变更，近影响单一服务。这是由于影响多个服务的变更，需要跨多个部门协调，这会减缓开发速度。另外一个从OOD由来的有用的原理，是共同闭合原理（CCP），它指出相同原因发生改变的类应该在同一个包。例如，两个类可能实现了相同业务规则的不同方面。最终目标是，当业务规则改变了开发人员，仅需要改动（理想情况下一个）包里很少的代码。设计服务时，这样的思考很有意义，它将帮助确保变更仅影响一个服务。

困难

如何拆分应用程序到服务？

限制

• 架构必须稳定
• 服务必须有凝聚力。一个服务应当实现一小组强关联的功能。
• 服务必须符合共同闭合原理 - 一起变更的事物应该打包在一起 - 确保变更仅影响一个服务
• 服务必须松散耦合 - 每个服务作为API封装了它的实现。这些实现在不影响客户端的情况下发生更改。
• 服务需要可测试
• 每个服务需要小到足够“2个披萨”团队开发，例如：6-10人的团队
• 每个拥有一个或多个服务的团队必须是自治的。团队应该在最小程度与其他团队合作的情况下，开发和部署他们的服务。

解决方案

定义服务为对领域驱动设计（DDD）的子域负责。DDD将应用中的困难区域-业务逻辑-指为领域。一个领域存在多个子域。每个子域为业务的不同部分负责。

子域可以按如下方式分类：

• 核心 - 业务的关键差异化因素，和应用中最有价值的部分
• 支持 - 业务相关，但不是关键差异化因素。这部分可以内部或外包实现。
• 通用 - 不是特定于业务，理想情况下用现有的软件实现

示例

一个在线商城拥有以下子域：

• 产品分类
• 库存管理
• 订单管理
• 物流管理
• 。。。

对应的微服务架构应该拥有对应每个子域的服务。

image

结果

这个模式有以下优势：

• 子域相对稳定，因此这个架构也稳定
• 开发团队是跨功能的，自治的，按产生业务价值组织而不是技术特点组织
• 服务是凝聚的，且松散耦合

问题

有以下问题需要解决：

• 怎么识别子域？识别子域和服务需要对业务的理解。与业务能力类似，识别子域可以分析公司的目标，组织结构，业务行为，专业领域。在迭代中最好标识出一个有界上下文。标识子域的起点最好是：

• 组织架构 - 公司里的不同小组对子域负责

• 高层次领域模型 - 子域通常有一个核心的领域模型

相关模式

• 按业务能力拆分是另一种替代模式