為甚麼要先想清楚目標？

在昨天聊到中小企業的痛點後，今天就要進一步思考：
我們的專案到底要解決什麼問題？該用什麼技術來完成？

很多人(包含我自己)寫 Side Project 常常都是 「想到什麼就先開一個專案跑起來」，結果寫到一半才發現根本解決不了需求，最後只能爛尾或乾脆直接不做了。

所以在這次鐵人賽，我希望能把「專案目標」跟 「技術選型」先定義清楚，未來每天的文章跟實作才不會偏離方向。

專案目標

這個 LINE 訂單系統的第一版（MVP）目標很單純，但背後其實蘊含了中小企業的真實需求：

1. 顧客可以直接在 LINE 下單

   • 不再需要打電話、傳訊息到不同平台，也不用教客人怎麼用網站。

   • 讓「下單」這件事變得像傳訊息一樣自然，降低顧客流失率。

2. 訂單自動寫入資料庫

   • 店家不必再抄在記事本、或散落在 LINE 聊天紀錄裡。

   • 資料集中管理，未來才能做統計報表、銷售分析，幫助老闆看懂營運狀況。

3. 店家即時收到通知

   • 有新訂單就能馬上知道，不會再漏單。

   • 對中小企業來說，效率就是服務品質，速度就是競爭力。

4. 顧客可以查詢訂單狀態

   • 減少重複電話或訊息詢問，店家省下時間，顧客也安心。

   • 這不只是方便，而是建立一種信任感──「我的單有人在處理」。

為什麼這些目標重要？

很多中小企業不是沒能力做網站，而是沒有資源去維護、經營。
他們需要的不是一個「華麗的電商平台」，而是一個能落地、能解決眼前問題的工具。

所以，這個專案的使命不是「寫一個很炫的系統」，而是：
👉 把複雜的訂單管理，變成 LINE 對話裡的一件小事。

換句話說，我們要把「傳統訂單流程」轉換成一個更流暢的「LINE 訂單流程」，讓老闆和顧客都輕鬆一點。

傳統 vs LINE 訂單流程（ 比較圖 ）

技術選型

在確立了專案目標之後，接下來要決定「用什麼技術來落地」。
這裡的選擇不是為了炫技，而是針對中小企業訂單系統的需求，找出最合適、最能快速驗證的組合。

1. LINE OA（官方帳號）+ Messaging API

• 定位：系統的入口點。

• 角色：顧客透過 LINE 互動，不需要額外學習或安裝 App。

• 應用：

  • Webhook 接收顧客訊息與操作事件。

  • Reply API 用來回覆顧客（例如「訂單建立成功」）。

  • Push API 主動通知店家（例如「有新訂單」）。

這讓 LINE 成為「下單的最短路徑」，最大程度降低顧客的使用門檻。

2. Node.js + Express.js

• 定位：後端應用核心。

• 角色：負責承接來自 LINE 的請求，並執行業務邏輯。

• 應用：

  • 建立 RESTful API，處理「建立訂單、查詢訂單、更新狀態」等功能。

  • Middleware 處理驗證、錯誤紀錄、請求流程。

  • 未來串接金流、物流等第三方 API，都會在這層擴充。

它就像「系統大腦」，協調各個元件的合作。

3. MongoDB

• 定位：主要資料庫。

• 角色：存放訂單、顧客與商品資訊。

• 應用：

  • 採用文件型結構（JSON-like），對「訂單內容多變、欄位不固定」的情境非常合適。

  • 能快速應對不同店家的需求變化（例：有些需要備註，有些需要送貨方式）。

  • 可搭配 MongoDB Compass，讓開發與測試更直觀。

與 Node.js 的物件模型天然契合，能加速開發。

4. Redis

• 定位：輔助型資料庫。

• 角色：提供快取與訊息佇列，確保系統即時與穩定。

• 應用：

  • 快取：將熱門或常查詢的資料（如熱門商品、最新訂單）暫存在記憶體，減少對主資料庫的壓力。

  • 訊息佇列：當大量訂單同時進入時，Redis 可用來排隊處理「通知工作」，避免伺服器瞬間超載。

  • 即時性：能確保店家在第一時間收到新訂單提醒。

這使得系統能在尖峰時段依然保持流暢，不會因單一環節卡住。

總結

這四個技術搭配起來，剛好能兼顧：

• 易用性（LINE OA，降低顧客進入門檻）

• 可擴充性（Node.js，方便加入新功能）

• 彈性（MongoDB，對應不同訂單格式）

• 即時性（Redis，確保通知不延遲）

換句話說，這是一個「以 LINE 為前端，Node 為核心，MongoDB 為基礎，Redis 提升體驗」的組合。

系統架構及資料流 - 以圖描述

系統架構圖

這張架構圖展示了整個 LINE 訂單系統的資料流：

• 顧客透過 LINE 官方帳號下單，事件會傳送到 Node.js / Express 應用。

• 系統將訂單資料寫入 MongoDB，並利用 Redis 提供快取與佇列處理。

• 新訂單會即時推播到 店家群組，同時管理者也能透過 Admin 後台（LIFF / Web） 呼叫 API 進行操作。

下單到通知（ 序列圖 ）

有了整體架構之後，我們再把焦點放到「一次下單」會發生什麼事。上面這張序列圖，展示了 從顧客下單 → 資料建立 → 店家通知 的完整流程：

1. 顧客 在 LINE 官方帳號裡點選商品選單或傳送表單。

2. LINE 官方帳號 會將事件透過 Webhook 丟給後端（Node.js/Express.js）。

3. 後端 建立一筆訂單資料，寫進 MongoDB，同時也把通知任務寫入 Redis，方便快速處理。

4. 系統立即回覆顧客一則 Reply 訊息（例如「訂單建立成功」）。

5. 接著，系統會透過 Push API 將新訂單的摘要推播到 店家群組，讓商家即時掌握狀況。
   👉 簡單來說，就是 「顧客下單 → 系統存檔 → 顧客確認 → 店家即時通知」 的完整閉環。

為什麼不用 SQL？

有人可能會問：訂單不是很典型的「表格型資料」嗎？為什麼不用 MySQL 或 PostgreSQL？
其實這裡並不是「MongoDB 比 SQL 好」，而是：

• 一開始我們只需要快速把 MVP 做出來，MongoDB 建立 Schema 速度更快。
• 之後若要做更複雜的會計/財務報表，再考慮引入 SQL。

總結

今天我們定義了專案的核心目標，並決定了技術選型。
明天會更深入聊「LINE 官方帳號與 Messaging API」，讓我們真正把這個入口打開！