以圖表思考

圖表無所不在 *#

使用 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 架構以表達「如何」而不是「什麼」。然後，您可以改善您的實作細節，而不會中斷與舊有客戶端的介面。

一次一步#

更頻繁地取得驗證和回饋

不要嘗試一次就建立整個業務領域的模型。相反地，一次只建立您在一個情境中需要的架構部分。透過逐步擴充架構，您將更頻繁地取得驗證和回饋，以引導您建立正確的解決方案。