以图的方式思考

处处皆图¹

在 GraphQL 中，您可以将业务领域建模为图

图是模拟许多现实世界现象的强大工具，因为它们类似于我们对底层过程的自然思维模型和口头描述。在 GraphQL 中，您通过定义架构（Schema）将业务领域建模为图；在架构中，您定义不同类型的节点以及它们如何相互连接/关联。在客户端，这创建了一个类似于面向对象编程的模式：引用其他类型的类型。在服务器端，由于 GraphQL 仅定义接口，您可以自由地将其与任何后端（新的或遗留的！）配合使用。

通用语言

命名是构建直观 API 的难点，也是重要组成部分

将您的 GraphQL 架构视为团队和用户之间的一种富有表现力的通用语言。要构建一个好的架构，请审视您用来描述业务的日常语言。例如，让我们尝试用简单的英语描述一个电子邮件应用

• 一个用户可以拥有多个电子邮件账户
• 每个电子邮件账户都有地址、收件箱、草稿箱、已删除邮件和已发送邮件
• 每封电子邮件都有发件人、接收日期、主题和正文
• 用户在没有收件人地址的情况下无法发送电子邮件

命名是构建直观 API 的难点，也是重要组成部分，因此请花时间仔细思考什么才符合您的问题领域和用户。您的团队应该对这些业务领域规则建立共同的理解和共识，因为您需要为 GraphQL 架构中的节点和关系选择直观、持久的名称。尝试想象一些您想要执行的查询

获取我所有账户收件箱中的未读邮件数量

{
  accounts {
    inbox {
      unreadEmailCount
    }
  }
}

获取主账户中前 20 封草稿的“预览信息”

{
  mainAccount {
    drafts(first: 20) {
      ...previewInfo
    }
  }
}
 
fragment previewInfo on Email {
  subject
  bodyPreviewSentence
}

业务逻辑层

业务逻辑层应作为执行业务领域规则的单一事实来源

您应该在哪里定义实际的业务逻辑？在哪里执行验证和授权检查？答案是：在专用的业务逻辑层内。业务逻辑层应作为执行业务领域规则的单一事实来源。

在上面的图中，进入系统的所有入口点（REST、GraphQL 和 RPC）都将使用相同的验证、授权和错误处理规则进行处理。

处理遗留数据

倾向于构建描述客户端如何使用数据的 GraphQL 架构，而不是镜像遗留数据库架构。

有时，您会发现自己在使用不能完美反映客户端如何消费数据的遗留数据源。在这种情况下，倾向于构建描述客户端如何使用数据的 GraphQL 架构，而不是镜像遗留数据库架构。

构建您的 GraphQL 架构来表达“如何做”而不是“是什么”。这样，您就可以改进实现细节，而不会破坏与旧客户端的接口。

循序渐进

更频繁地获得验证和反馈

不要试图一次性为整个业务领域建模。相反，一次只构建一个场景所需的架构部分。通过逐步扩展架构，您将更频繁地获得验证和反馈，从而引导您构建正确的解决方案。

下一课

通过 HTTP 服务

探索 GraphQL 如何在 HTTP 上运行，包括方法、标头、状态码和 API 端点设计。

前往下一课 教程