グラフで考える

全てがグラフで繋がっている *#

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スキーマを構築します。そうすれば、古いクライアントとのインターフェースを壊すことなく、実装の詳細を改善できます。

一度に一つずつ#

より頻繁に検証とフィードバックを得る

ビジネスドメイン全体を一度にモデル化しようとしないでください。代わりに、一度に1つのシナリオに必要なスキーマの部分のみを構築します。スキーマを徐々に拡張することで、より頻繁に検証とフィードバックを得て、適切なソリューションの構築へと導くことができます。