软件架构：核心挑战

第 5 章 基于构件的分解模式 基于组件的分解模式

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

Monday, November 1, 11:53

Addison 和 Austen 选择使用基于组件的分解方法，，但不确定每种分解模式的细节。他们试图研究这种方法，但在互联网上没有找到太多相关信息。他们再次与 Logan 在会议室会面，就这些模式的内容和使用方法寻求建议。

"听着，洛根，"艾迪森说，"首先我想说的是，我们都非常感谢你花了这么多时间和我们一起启动这个迁移过程。我知道你忙于自己的战斗。"

"没问题，"洛根说。"我们消防员必须团结一致。我以前也和你们一样，所以我知道在这种事情上盲目飞行是什么滋味。此外，这是一次非常引人注目的迁徙工作，你们俩必须第一次就把事情办好。因为不会有第二次了。"

"谢谢你，洛根。"奥斯汀说。"我两小时后还有一场比赛，所以我们尽量长话短说。你刚才谈到了基于组件的分解，我们选择了这种方法，但我们在互联网上找不到太多关于它的信息。"

"我并不感到惊讶，"洛根说。"关于这些模式的文章还不多，但我知道今年晚些时候会有一本详细描述这些模式的书问世。我第一次了解这些分解模式是在大约四年前的一次会议上，一位经验丰富的软件架构师与我进行了交流。他用迭代和有条不紊的方法将单体架构安全地转变为分布式架构（如基于服务的架构和微服务），给我留下了深刻印象。从那以后，我一直在使用这些模式，并取得了不小的成功。

"你能告诉我们这些图案是如何工作的吗？"艾迪生问道。

"当然，"洛根说。"让我们一个模式一个模式来吧。"

基于组件的分解（在第 4 章中介绍）是一种 非常有效的技术，当代码库具有一定的结构并按命名空间（或目录）分组时，它可以分解单体应用程序。本章将介绍一组模式（称为基于组件的分解模式），这些模式描述了如何重构单体源代码，以获得一组定义明确的组件，这些组件最终可以成为服务。这些分解模式大大减轻了将单体应用程序迁移到分布式架构的工作。

图 5-1展示了本章介绍的基于组件的分解模式的路线图，以及如何将这些模式用于分解单体应用程序。最初，在将单体应用程序迁移到分布式应用程序时，这些模式会按顺序一起使用，然后在迁移过程中对单体应用程序进行维护时单独使用。这些分解模式总结如下：

"识别和确定部件尺寸模式"

通常是拆分单体应用程序时采用的第一种模式。这种模式用于识别、管理和适当调整组件的大小。

"收集通用领域组件模式"

用于整合应用程序中可能重复的通用业务域逻辑，从而减少分布式架构中可能重复的服务数量。

"扁平化组件图案"

用于折叠或扩展域、子域和组件，从而确保源代码文件只存在于定义明确的组件中。

"确定组件依赖模式"

用于确定组件依赖关系，完善这些依赖关系，并确定从单体架构迁移到分布式架构的可行性和总体工作量。

"创建组件域模式"

用于将组件归入应用程序中的逻辑域，并重构组件命名空间和/或目录，以便与特定域保持一致。

"创建域名服务模式"

用于将单体应用程序中的逻辑域移动到单独部署的域服务，从而对单体架构进行物理拆分。

图 5-1. 基于组件的分解模式流程和用法

本章介绍的每种模式都分为三节。第一节 "模式描述 "介绍了模式的工作原理、模式的重要性以及应用模式的结果。由于大多数系统在迁移过程中都是移动目标，因此第二节 ...