企业官网建设流程全解析

题目背景

某连锁餐厅计划开发一套分布式 Web 应用点餐系统，采用“终端—云端”双层架构以提高运行效率与用户体验。终端层部署若干个门店的智能点餐设备，顾客扫码登录后，可实时浏览菜单商品信息、下单支付，并支持加菜、退单等操作。云端层作为管理中枢，负责数据持久化与业务逻辑处理，包含菜单基础信息维护、订单全生命周期管理、餐厅菜单动态配置以及员工权限管理。

【问题1】（6分）：领域驱动开发

点餐系统采用领域驱动的开发方法，说明在领域驱动中，限界上下文的定义以及作用。（6分）

参考答案：

限界上下文（Bounded Context）指通过“边界”来划分业务的上下文，以明确不同子领域在什么范围内成立、使用各自的领域模型与术语。它是一种划分业务边界的方法。

在点餐系统中，限界上下文的作用包括：

• 分解复杂度：将系统按业务边界拆分，便于每个模块专注于特定业务逻辑；
• 对齐共识：确保开发人员、产品经理与业务方在各自边界内对领域模型形成一致理解，减少歧义；
• 提升可维护与可扩展：通过清晰边界与接口交互，降低耦合，让系统更容易演进与扩展。
  

举例说明：电商系统里可以把“用户管理”“订单处理”等拆分为不同限界上下文。用户管理负责注册、登录与权限；订单处理负责订单创建、状态流转；支付结算负责资金转移与对账。各上下文通过明确接口交互（例如订单系统调用支付接口），从而既保持高内聚，又降低耦合。

【问题2】（11分）: 系统架构设计

项目组完成了餐厅点餐系统的系统架构设计方案。系统架构如图所示。请从选项(a) ~ (n)中为架构图中(1) ~ (11)处空白选择相应内容，补充餐厅点餐系统架构设计图。（11分）

选项：

(a) 数据持久层、 (b) 服务层、(c)表示层、 (d) 统一代理层、(e) 业务层、 (g) Ajax、(h) 日志操作、 (i) Sqlite、 (j) Realm、 (k) Spring Security、(l) Ktor、 (m) 基础配置层

参考答案（(1)~(11)填空）：

• (1) →(c)表示层
• (2) → (l) Ktor
• (3) → (g) Ajax
• (4) → (d) 统一代理层
• (5) → (k) Spring Security
• (6) → (e) 业务层
• (7) → (m) 基础配置层
• (8) → (h) 日志操作
• (9) → (f) 桌台
• (10) → (a) 数据持久层
• (11) → (i) Sqlite

• Ktor 是一个用于 Kotlin 的后端/服务端开发框架，用来快速搭建 Web 服务与 API（也常用于做网关、HTTP 接口、路由处理等）。在你这张架构图里，它被当作“服务端框架/统一服务层”这一类的组件来填空。
• Ktor = Kotlin 编写的服务端框架，用于处理 HTTP 请求/路由与服务业务逻辑。

Sqlite 指的是 SQLite（常写作 SQLite / Sqlite），是一种 轻量级的嵌入式数据库。

• 它是什么：一个自带在应用里、通过一个文件就能存数据的数据库（不需要单独部署数据库服务器）。
• 为什么放在架构图中：通常用来做移动端/离线场景的数据存储（例如本项目中终端离线缓存、临时保存订单或业务数据），和后续网络恢复再同步到云端。
• 和 MySQL/Redis的区别：MySQL 更偏“服务端数据库”，Redis 更偏“内存缓存”，而 SQLite 更偏“本地持久化、轻量可靠”。
• 一句话总结：SQLite = 跑在本地的轻量数据库，用文件存数据，适合离线/嵌入式终端存储。

【问题3】（8分）：数据同步策略

云端到终端以及终端间同步在网络出现数据丢失、冲突等问题时，应该如何解决，给出相应的方案。

参考答案：

1. 针对数据丢失问题：
   任何操作先写入本地数据库；再由后台的消息队列与自动重试机制，在网络恢复后将数据同步至云端。同步过程对用户透明，系统最终保证数据一致。

2. 针对数据冲突问题：
   冲突的意思是“多个终端同时在改同一个订单”。我们用两招减少冲突：
   （1）先规定权限：主要修改只让“创建终端”负责，其他终端只做受限操作（例如支付只让收银终端做）。
   （2）再加版本号：订单里有一个“版本号”，谁要更新就把自己看到的版本号带上；云端发现版本不一样就不直接覆盖，并提示重新同步。 能按规则自动合并就自动合并；合并不了就让用户/工作人员选一个结果，避免数据被互相覆盖。

3. 针对操作延迟问题：
   （1）用户在本地先做“立刻可见”的响应：先把界面更新/标记为“处理中”，后台再去同步云端。云端同步成功就保留结果；失败就回滚撤销本地结果。
   （2）给每次操作一个“临时操作号”（相当于占位ID）。网络慢或重试时，就算请求发多次，也会被云端当成“同一件事”去处理：云端返回正式ID后，再把本地的临时号替换掉。这样就能避免用户重复点/网络重发导致重复下单或重复处理（幂等/去重）。