图式思维

图式无处不在 *#

使用 GraphQL，您可以将您的业务领域建模为一个图

图是建模许多现实世界现象的强大工具，因为它们类似于我们自然的思维模型和对底层过程的口头描述。使用 GraphQL，您可以通过定义一个模式将您的业务领域建模为一个图；在您的模式中，您可以定义不同类型的节点以及它们如何相互连接/关联。在客户端，这会创建一个类似于面向对象编程的模式：引用其他类型的类型。在服务器端，由于 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 架构以表达“如何”而不是“什么”。然后，您可以改进您的实现细节，而不会破坏与旧客户端的接口。

一次一步#

更频繁地获取验证和反馈

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