餐饮预定系统架构拆解：订单链路、权限组织与私有化源码交付

国内地级市小微经营者评估「餐饮预约系统源码」时，技术评审应先看到可部署的模块边界，而不是先争论平台抽成比例。下文用目录树、技术栈列表、部署片段与验收清单说明餐饮预定三端（用户端 / 门店端 / 运营后台）如何落在同一套私有化交付里。示例配置为教学示意。

模块目录树（教学示意）

餐饮预定单模块在中台解耦后，仓库可按服务边界拆分（名称以当期交付为准）：

text 复制代码

dining-reservation-platform/
├── gateway-service          # API 网关：鉴权、限流、路由
├── auth-service             # 登录与 Token
├── user-app-service         # 用户端：选店、选时段、下单、改取消
├── store-app-service        # 门店端：预约列表、核销、改期处理
├── reservation-service      # 预约订单聚合与状态机
├── table-slot-service       # 桌台模板、时段策略、库存扣减
├── settlement-service       # 订金/预付字段与导出任务
├── admin-api                # 运营后台 API
└── deploy/
    ├── docker-compose.yml
    └── env.example

抽成顾虑在架构评审里应改写为：settlement-service 是否按角色导出、异常是否回写应结字段。系统侧不抽成客户平台订单------这是交付边界。

技术栈列表（示意）

后端：Java + Spring Boot / Spring Cloud Gateway
前端：Vue 管理端；用户端与门店端按当期方案（App/小程序/H5）
数据：MySQL 8（预约订单与权限）；Redis（会话、时段热点缓存、短时锁）
消息：RabbitMQ 或等价组件（状态变更异步通知）
部署：Docker + Nginx；私有化源码/制品交付到客户环境

配置与部署片段（示意）

yaml 复制代码

# deploy/env.example（示意，勿直接用于生产）
MYSQL_HOST: 127.0.0.1
MYSQL_DB: dining_reservation
REDIS_HOST: 127.0.0.1
MQ_HOST: 127.0.0.1
JWT_ISSUER: dining-res-local
STORE_SCOPE_ENFORCE: "true"
DEPOSIT_ENABLED: "false"

bash 复制代码

# 教学示意：拉起依赖与应用（以交付脚本为准）
docker compose -f deploy/docker-compose.yml up -d mysql redis mq
docker compose -f deploy/docker-compose.yml up -d gateway reservation-service table-slot-service

客户侧需自备域名证书、支付/短信密钥（若启用订金）。环境差异表应进入验收附件。

预约链路：架构层怎么验

架构验收关注「谁触发、谁持久化、谁广播」：

user-app-service 创建预约 → reservation-service 落库并锁定时段库存
store-app-service 接收通知，展示当日列表
到店核销或标记未到 → reservation-service 更新状态枚举
settlement-service 在完结或取消后生成可导出明细
admin-api 按权限读取同一状态；非法跳转应由 reservation-service 拒绝

时段库存扣减与释放必须在 table-slot-service 内原子完成，避免超卖。

状态枚举与验收清单

text 复制代码

PENDING_CONFIRM → CONFIRMED → ARRIVED → COMPLETED
                ↘ CANCELLED / NO_SHOW / RESCHEDULED

用户端：时段可见、改取消受规则约束、状态与门店侧一致
门店端：仅本店预约可见；核销写权限可单独关闭
运营后台：桌台模板、时段策略、角色模板、审计日志
导出：订金/预付字段、异常原因码、操作人时间戳

中台解耦与单模块边界

餐饮预定可单独采购部署，共享统一中台底座的用户、权限、营销等公共能力。中台侧能力升级时，单模块实例可同步受益，而不必重建整套系统。首期验收只覆盖 reservation 域；外卖、团购等模块在书面范围内后期挂载即可。

订金与取消：状态机补充（示意）

sql 复制代码

CREATE TABLE reservation_deposit (
  reservation_id BIGINT PRIMARY KEY,
  deposit_amount   DECIMAL(10,2) NOT NULL DEFAULT 0,
  pay_status       TINYINT NOT NULL COMMENT '0=NONE 1=PAID 2=REFUNDING 3=REFUNDED',
  updated_at       DATETIME NOT NULL
);

取消路径应区分：未付订金、已付订金待退、已核销不可退。每种路径导出字段不同，验收时需各跑一笔。

与中台公共域的接口边界

餐饮预定通过 internal API 读取 user_profile 与 merchant_staff；不直接跨模块写外卖订单表。后期叠加模块时，网关按 module_code 路由即可。

试点两周节奏（技术向）

第一周：环境拉起、桌台模板导入、正常预约与取消各一笔、导出 CSV 归档。第二周：加测改期、未到、订金支付回调（若启用）、门店越权 403。断点未清零不扩第二家店。

table_slot 库存扣减 SQL（示意）

sql 复制代码

UPDATE table_slot_inventory
SET reserved_count = reserved_count + :party_size
WHERE store_id = :store_id
  AND slot_id = :slot_id
  AND service_date = :service_date
  AND capacity - reserved_count >= :party_size;
-- affected_rows=0 时应返回「时段已满」，而不是静默失败

改期应先 release 旧 slot 再 lock 新 slot，同一事务内完成，避免双占或泄漏。

admin-api 权限注解（示意）

java 复制代码

@PreAuthorize("hasStoreScope(#storeId)")
@GetMapping("/stores/{storeId}/reservations")
public List<ReservationVO> list(@PathVariable Long storeId) { ... }

门店员工账号带 store_id 声明；越权访问邻店应 403 并写 audit_log。

专项定制：书面范围示例（示意）

text 复制代码

首期包含：用户端/H5 订位、门店核销、桌台时段模板、基础导出 CSV
后期可选：订金支付对接、短信模板、CRM 字段扩展、多店连锁权限
不包含：外卖配送、团购秒杀（需另启 module）

未写入首期的一律单独报价，避免专项定制预算被隐性追加拖垮。

纯技术小结

「餐饮预约系统源码」选型应压到模块树、状态机、时段库存与私有化部署边界。光合同城餐饮预定按国内单模块成品交付，适合先小范围闭环，再按书面范围扩面或定制。抽成话题落到 settlement 导出与权限域，比争论比例更接近工程事实。