本文核對的來源版本（eaf76fa3，分頁於 v0.15.6 加入）把訂單管理分成明細、樓層數、總數三個分頁。查一位同事訂了什麼、把便當分到各樓層、告訴店家要準備幾份，是三種不同工作；如果都擠在一張明細表裡，使用者就得自己算。

Repo 的 ORDER_SUMMARY_TABS 固定這三個入口。AdminOrderSummary 預設顯示明細，總數則從同一份 adminSummary.todayOrders 聚合，而不是重新抓一份獨立資料。分頁與聚合實作

同一份訂單可以依工作需要產生不同讀取視圖（read model）；分頁可以有自己的分組方式，不能各自決定哪些訂單算數。

先決定資料範圍，再決定怎麼看

後端 getAdminSummary 先依指定日期讀取訂單與訂單品項，套用共用的狀態條件，再產生 todayOrders、總份數、總金額及樓層統計。後端摘要

狀態條件尤其容易被忽略：當日資料採有效訂單；查歷史日期時，還要包含已完成的訂單。取消訂單不應混進這兩類統計。測試定義專門比較歷史與當日摘要，避免只用「有效訂單」四個字掩蓋差異。歷史／當日摘要測試

如果前端每個分頁又自行篩一次狀態，新增歷史查詢時就可能只修到其中一頁。把範圍決定留在共用讀取路徑，後面的聚合才有一致的起點。

這裡核對的是來源實作與測試條件。另於 2026-10-03 擷取顯示 v0.15.4 的統一報表，查詢日期為 2026-10-02；它提供舊版同頁區塊的實際畫面，不能證明較新三分頁已部署或通過跨頁驗收。

明細回答誰，樓層回答怎麼分，總數回答做多少

三個視角可以保留不同資訊：

前端的 groupOrdersByFloor、aggregateOrdersByFloor 和 aggregateOrdersByItem 接受同一類訂單列。樓層排序還會先抽出數字，所以不會單靠字串順序把 10 樓排到 2 樓前面。聚合函式

可以用一組明確標為示意的輸入檢查理解：同一品項在 1 樓有 2 份、9 樓有 3 份，樓層視角保留 2 與 3，總數視角得到 5。這個例子沒有新增訂單，也沒有改金額，只改變讀者看到的分組。

這種從既有資料產生特定視角的做法，就是投影（projection）。在這個小系統裡，它是幾個查詢與聚合函式，不需要因此宣稱已經建立一套大型讀寫分離架構。

「相加能對上」還不夠，分組鍵也有邊界

目前前端品項聚合使用 item_name 作為鍵。同名品項會被加在一起。這對按名稱報餐數的畫面很直接，但不能外推成「所有同名、不同規格的餐點都能自動區分」。

若未來兩個不同規格共用相同顯示名稱，就必須先決定營運上要合併還是拆開，再選擇穩定品項識別或包含規格的複合鍵。單純替畫面多加一個欄位，不會修正已經合併的數量。

這是讀取視圖的實際代價：它為某個工作省略資訊，也可能失去另一個工作需要的差異。新增視圖前，要先說清楚什麼可以被合併。

把「再做一張表」改成可核對的需求

AI 很快能寫出新的 map、reduce 或 SQL。比較容易漏掉的是，這一份計算究竟應沿用哪些舊語意。

下次再新增統計視角時，可以先固定三件事：

1. 輸入集合：日期和訂單狀態由哪條共用路徑決定？
2. 分組鍵：同名、不同規格、空樓層要如何處理？
3. 可核對結果：同一輸入的各樓層份數，加總後是否等於不分樓層的份數？

最後一項是應加進驗收的交叉核對，不代表本篇已對正式資料執行過。它能把「三頁看起來都正常」縮成一個可以檢查的數量關係。

這次需求沒有要求新的資料權威，只要求同一批訂單能服務不同營運工作。分頁增加後，最值得保留的限制是：展示可以分流，哪些訂單有效仍要有共同答案。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

下一篇會把「同一份資料怎麼看」往時間軸再推一步：今天為了讓畫面更完整補上的資訊，有沒有資格變成昨天就存在的事實？