Headless Shopify 架構圖若只有「前端 → Storefront API → Shopify」，還不足以建置。正式商店還有內容、搜尋、顧客帳號、購物車、結帳、分析、金物流、部署和營運後台。每一條線都要說明資料方向、認證、快取、失敗處理和 owner。
架構圖的用途是讓產品、工程、內容與營運對系統邊界有共同理解，不是為了放更多技術 logo。
第一層：顧客接觸面
列出網站、App、門市裝置、活動頁與其他 storefront。每個接觸面標示網域、市場、語言、runtime、發布方式和主要旅程。若多個前端共用商品與內容，也要說明哪些能力真的共用，哪些有自己的 release cycle。
瀏覽器和 server runtime 分開畫。Public Storefront token 可以用於顧客端情境，private token、CMS draft token 和後台憑證必須留在安全 server 環境。
第二層：Shopify commerce domain
將商品、variant、collection、price、inventory availability、cart、customer 和 checkout 標入 Shopify。Storefront API 提供顧客購物所需資料；Customer Account API、Admin API 與 webhook 有不同權限和用途，不能用一支萬能 API 代替。
購物車和 checkout 要畫成狀態流程。前端建立或更新 cart，準備付款時使用 Shopify checkout URL。折扣、selling plan、buyer identity、市場與幣別如何進入 cart，都要在 API contract 中定義。
第三層：內容與搜尋
商品交易資料通常以 Shopify 為主，品牌故事、文章、活動與導購內容可由 CMS 管理。畫出內容模型、reference、預覽、翻譯、發布 webhook 與 cache invalidation。若 CMS 也存商品名稱或價格，要標明同步與衝突規則，避免顧客看到過期交易資訊。
搜尋系統則需要索引來源、更新事件、ranking、同義詞、庫存與市場過濾。前端搜尋失效時的退路也要畫出，例如回到集合導覽或顯示可理解的錯誤。
第四層：整合與事件
ERP、PIM、WMS、CRM、客服、評論、忠誠和 email 不一定直接連 storefront。使用 integration service、queue 或 App 接收 Shopify webhook，再依 idempotency、retry 和 dead-letter 規則處理。即時與批次流程用不同線型，並標出可接受延遲。
每個資料欄位指定 source of truth。庫存由 WMS 回寫 Shopify，商品敘述由 PIM 或 Shopify 管理，顧客同意由哪個系統保存，都不能留白。
第五層：分析與同意
把 consent manager、client events、server events、GA4、廣告平台和資料倉庫畫在旅程旁。定義 event schema、event_id、幣別、使用者識別與去重。付款完成頁、server webhook 和 Shopify 訂單若都送 purchase，需要一個明確去重設計。
分析故障不應阻斷付款；未取得同意時，非必要標籤也不能先載入。架構圖要呈現這些控制關係。
第六層：部署與可觀測性
畫出 Git、CI、preview、staging、production、CDN、cache、secret store、log、error tracking、uptime 和 alert。每個環境使用哪個 Shopify storefront、CMS dataset 和搜尋 index，也要明確區分。
接著加上失敗路徑：Storefront API timeout、CMS 無法連線、搜尋失效、webhook 積壓和 deployment 回歸時，顧客看到什麼、告警給誰、如何降級或回復。
最後做責任矩陣，讓每個方塊和連線都有 owner、SLO、文件與測試。架構圖應隨系統變更更新，並連到更詳細的 API、資料和事件規格。需要共同盤點時，Headless Shopify 服務可作為 storefront、CMS、整合與維運範圍的起點。