概览
我们已经进入迁移计划的最后一步：开始将子图分成小块！这一步实际上非常重要，我们可以进一步将其细分为多个步骤。在本课中，我们将 :
- 决定哪些 子图将成为我们超图的一部分
- 还将使用一个模板设置另一个 子图
规划和准备
确定从何处开始拆分 子图会让人不知所措。如果您有一个大型复杂图表，有多个团队参与，并且客户端依赖于它的持续操作，尤其如此。我们建议牢记联合的核心原则：逐步采用。我们将一次按一个问题解决单片子图的功能。
为了帮助我们进行规划，我们将把它分解成几个步骤
- 识别实体
- 识别子图s
- 决定首先迁移哪些实体
1. 识别实体
一个实体是一个对象类型其字段分布在多个子图中。它是我们联合图的构建块。每个子图仅负责解析它为实体贡献的字段，并且每个实体实例都通过主键字段唯一标识。
花点时间阅读这篇文章monolith/schema.graphql文件并识别哪些对象类型应标记为实体。
当您准备就绪时，请查看下面的部分，将您的列表与我们的列表进行比较！
- Host- Guest- Listing- Booking- Review
您全部拿到了吗？
其他 对象类型呢？例如， 便利设施 是 对象类型，但它没有包含在我们的列表中，即使它可以唯一标识（每个 便利设施 拥有自己的 ID 字段）。 便利设施 类型更像一个附加到 列表 的属性，而且它很可能不会在 子图 中分解开任何 字段。
用户 界面呢？我们可以将其变成 实体，但 字段 在 用户 界面中都与唯一的用户相关。如果它有额外的 字段，我们可以分解到其他 子图 中，我们可能考虑将其变成 实体（我们未来仍然可以做到！）。
此外，我们无法将以下类型标记为实体：枚举（如 便利设施类别），输入（如 搜索列表输入）和 变更 响应（如 创建列表响应）。
2. 识别子图
我们现在应该更清楚我们将创建哪些 子图来管理不同的域职责。我们还可以考虑我们组织团队的结构、目前存在的服务或 数据源以及我们要构建的未来功能。
再次，花点时间考虑你可能如何为 子图 Airlock 设计。准备就绪后，查看下面的章节，将你的清单与我们的进行比较！
- accounts- listings- bookings- reviews- payments
对于 Airlock，我们决定创建 5 子图。在第一课中，我们了解了账户团队和清单团队，他们各自分工负责，所以给他们各自的子图是有道理的。我们可以将所有预订功能合并到 listings 子图中；评论也是一样。但它们都感觉像是独立的大型域，也可以在它们自己的子图中进行处理。付款通常由第三方服务处理，因此为其提供自己的子图也合乎情理。
如果你的清单略有不同，那也没关系！没有单一的正确方式来设计模式。你可能会选择不同的名称，或者有更细化的范围。只要你能够表达你的决策背后的原因，那么你就可以进行下去了！记住，你总可以演化和迭代你的模式。
当所有迁移完成时，理想的 Airlock 联合架构将如下所示
我们一次处理一个 子图，将其从当前的单体子图中剥离出来。
3. 确定先迁移哪些实体
首先选择哪个 子图取决于你的产品和你的团队。在采用联合体时，我们建议你确定现有 GraphQL实现中一个意义不大且有价值的部分，将其隔离为第一个子图。
注意：有关示例场景，包括你可能提出的帮助做出此决策的类型的问题，请查阅 Apollo 技术说明中有关 “从 GraphQL 单体迁移至 Apollo 联合”。
那么我们应该在哪里开始？对于 Airlock，我们将从剥离 accounts 子图开始。此子图将负责与帐户和用户、登录详情和用户个人资料相关的所有事项。
在此课程中，我们仅介绍剥离 accounts 子图。其余的子图将留给您练习！
要点
- 一开始就为超图体系结构制定最终目标的计划，有助于了解从哪里开始。
- 记住联合的关键原则是渐进式采用。我们将从一个子图开始，一次采取小的操作步骤。
接下来
我们的计划已经制定好，现在让我们开始实施！
分享您对本课程的问题和评论
您的反馈有助于我们改进！如果您遇到困难或感到困惑，请告诉我们，我们会帮助您。所有评论都是公开的，并且必须遵循 Apollo 行为准则。请注意，已经解决或处理的评论可能会被删除。
您需要一个 GitHub 帐户才能发布以下内容。没有吗？ 转而发布在我们的 Odyssey 论坛中。