架构模式: 子领域分解
上下文
您正在开发一个大型，复杂的应用程序，并希望使用微服务架构。微服务架构将应用程序构建为一组松散耦合的服务。微服务架构的目标是通过实现持续交付/部署来加速软件开发。
微服务架构以两种方式实现：
- 简化测试并使组件能够独立部署
- 将工程组织构建为小型（6-10个成员）自治团队的集合，每个团队负责一个或多个服务
这些好处不会自动得到保证。相反，它们只能通过将应用程序细致地功能分解为服务来实现。
服务必须小到足以由小团队开发并且易于测试。面向对象设计（OOD）的一个有用的指导原则是单一责任原则（SRP）。SRP将类的责任定义为改变的理由，并声明类只应有一个改变的理由。将SRP应用于服务设计以及设计具有凝聚力的服务并实现一小组强相关功能是有意义的。
应用程序也以某种方式进行分解，以便大多数新的和更改的要求仅影响单个服务。这是因为影响多个服务的更改需要跨多个团队进行协调，这会降低开发速度。OOD的另一个有用原则是Common Closure Principle（CCP），它声明由于同样的原因而改变的类应该在同一个包中。例如，也许两个类实现了同一业务规则的不同方面。目标是当业务规则改变开发人员时，只需要更改少量代码（最好只有一个）的代码。在设计服务时，这种想法很有意义，因为它有助于确保每项更改只影响一项服务。
问题
如何将应用程序分解为服务？
要点
- 架构必须稳定
- 服务必须具有凝聚力。服务应该实现一小组强相关的功能。
- 服务必须符合通用关闭原则 - 将一起更改的内容打包在一起 - 以确保每个更改仅影响一个服务
- 服务必须松散耦合 - 每个服务作为封装其实现的API。可以在不影响客户端的情况下更改实现
- 服务应该是可测试的
- 每项服务都小到足以由“两个披萨”团队开发，即一个6-10人的团队
- 拥有一项或多项服务的每个团队必须是自治的。团队必须能够与其他团队进行最少的协作来开发和部署他们的服务。
结论
定义与域驱动设计（DDD）子域相对应的服务。DDD指的是应用程序的问题空间 - 业务 - 作为域。域由多个子域组成。每个子域对应于业务的不同部分。
子域名可分为以下几类：
- 核心 - 业务的关键差异化因素和应用程序中最有价值的部分
- 支持 - 与业务有关，但与差异化无关。这些可以在内部实施或外包。
- 通用 - 不是特定于业务，理想情况下使用现成的软件实现
例子
在线商店的子域包括：
- 产品目录
- 库存管理
- 订单管理
- 交货管理
- …
相应的微服务架构将具有与这些子域中的每一个相对应的服务。
结果上下文
这种模式具有以下好处：
- 由于子域相对稳定，因此结构稳定
- 开发团队跨职能，自主，有组织地提供业务价值而非技术特征
- 服务具有凝聚力和松散耦合
问题
有以下问题需要解决：
-
如何识别子域名？识别子域和服务需要了解业务。与业务功能一样，子域通过分析业务及其组织结构并识别不同的专业领域来识别。使用迭代过程可以最好地识别子域。识别子域名的良好起点是：
- 组织结构 - 组织内的不同组可能对应于子域
- 高级域模型 - 子域通常具有关键域对象