简介这是一份酒店管理系统概要设计说明文档面向软件开发人员、项目评审员及测试人员用于在详细设计与编码前明确系统的处理流程、功能分配、模块结构、接口关系和数据结构设计。文档以顾客就餐管理、顾客住宿管理、用户信息管理和数据库信息管理四大业务为主线逐项说明各模块的输入、处理过程与输出并覆盖总体设计、运行环境、基本设计概念、接口设计、运行设计、系统出错处理与维护设计等内容同时给出了从用户登录、密码验证、权限判断到具体业务操作的系统活动图。资源包为单份doc文档大小约206KB内容按标准概要设计说明书章节编排目录结构清晰便于快速定位到相应设计部分。目前已有45人学习/下载适合计算机相关专业课程设计、毕业设计或中小型酒店管理系统项目前期参考也可作为梳理同类系统架构与编写设计说明书的实用范例。1. 酒店管理系统概要设计说明先想清楚再写代码拿到一个“酒店管理系统概要设计说明.doc”大多数人第一反应是“又要写一份没人看的文档”。但如果你接过真实项目就知道概要设计是酒店管理系统开发里最容易返工、也最能省钱的环节。它要回答三个问题系统给谁用、模块怎么分、关键数据怎么流转。这份文档解决了“需求到代码之间的鸿沟”适合产品经理、项目经理、后端开发、甚至刚入职的初级工程师去读它能让你在写第一行代码前就能发现 80% 的设计缺陷。很多项目翻车不是因为码农水平不够而是概要设计里漏了免房、锁房、汇率、夜审这些业务细节。2. 概要设计文档怎么组织从边界到接口的五个核心段落一份能落地的酒店管理系统概要设计我一般建议按五个段落写系统边界、模块划分、数据流、数据库关系、接口约定。这五个段落有先后顺序边界不清会导致模块划分反复模块没定会导致数据流画不出来数据流没定会导致表结构瞎设计。下面逐个说明每个段落里到底要放什么以及需要做到什么粒度。2.1 用上下文图界定系统边界别急着画功能树很多概要设计第一页就是“系统管理模块、客房管理模块……”这是本末倒置。你应该先画一张上下文图把系统放在中间然后列出所有外部参与者和外部系统。对于酒店管理系统外部参与者通常有前台接待、宾客、客房服务员、财务人员、餐饮部员工、店长外部系统通常有OTA 渠道携程、美团、Booking、PMS 接口、公安登记上传平台、支付网关、短信服务商、税控系统、会员 CRM 系统。上下文图的价值在于它把“哪些数据是本系统内部职责”“哪些数据需要外部协作”一次性说清。比如公安登记上传如果概要设计阶段没写明由谁提供数据、何时触发上传、失败后怎么补偿开发时就会出现“前台办完入住公安系统一直查不到记录”的严重事故。我通常会在文档里用一个表格列出外部交互点如下。外部系统/参与者数据方向触发时机失败处理OTA 渠道入库订单与出库房态、价格用户下单/确认时订单状态标记为“待确认”定时同步公安上传平台出库客人实名信息入住登记完成后 10 秒内本地记录上传状态支持手动重传支付网关出库支付请求与回调预授权/收款时回调幂等订单支付状态以回调为准短信服务商出库验证码、订单确认短信预订成功/入住提醒发送失败不阻塞主流程记录日志CRM 系统出入库客史、会员、营销数据入住离店事件发生后发送失败进入重试队列日终对账边界确定后再画功能树就不容易跑偏。功能树里的每个功能都要能回溯到某个外部交互需求否则就是多余功能。2.2 模块划分高内聚低耦合的标准与粒度酒店管理系统常见的模块划分是前台管理、客房中心、餐饮 POS、财务应收、会员与 CRM、基础数据、系统管理。但很多人划分模块只看“功能分区”导致前台模块里塞了房价设置财务模块里又塞了订单冲销。我建议用三个标准来判断一个功能该属于哪个模块数据归属、变更频率、使用角色。数据归属指这个功能主要读写哪一组表。比如“房价管理”虽然前台常用但房价表的维护者是收益管理员变更频繁且影响全局所以归到基础数据模块更合适。“订单冲销”读写财务账务表归财务应收。变更频率上低频变更的配置类功能集中在基础数据高频交易类集中在业务模块。使用角色上同一个业务动作如果跨两个角色就要拆两个接口而不是一个页面让两个角色共用。下面是一个模块职责表可以在概要设计里直接照抄并裁剪。模块职责摘要核心数据对象依赖其他模块前台管理预订、入住、换房、退房、修改房价订单、房态、客人档案依赖于基础数据中的房价、房型客房中心房态清扫、维修申报、布草管理房态日志、客房任务读取前台入住数据餐饮 POS点菜、结账、厨打餐饮订单、支付流水依赖财务应收做汇总财务应收入账、离店结账、夜审、挂账、冲销账务流水、账单依赖前台订单和餐饮订单会员与 CRM会员注册、积分、券、客史分析会员档案、积分明细订阅订单和消费事件基础数据房型、房价计划、税率、杂费项目价格计划、商品档案无模块划分的粒度以“一个开发组 3-5 人两周能交付迭代”为参考。如果你把一个模块拆到 20 张表、10 个人开发那就要继续往详细设计推进不要停在概要设计。2.3 数据流从预订到入住、离店的三个状态机概要设计里最容易画错的是状态机。很多文档只有一个“订单状态”未确认、已确认、已入住、已离店。但酒店管理的实际业务远比这个复杂。我习惯把状态机拆成三个订单状态机、房态状态机、支付状态机。三个状态机互相联动但不混在一个状态字段里。订单状态机至少要包含预订单、已确认、已入住、已离店、已取消、未到店NoShow、提前离店、作废。房态状态机至少包含空房Vacant、干净Clean、脏房Dirty、检查中Inspected、维修房OOS、预分房Blocked、在住Occupied。支付状态机包含未支付、预授权、已收款、部分收款、挂账、退款中、已退款。下面用表格描述核心的订单状态迁移。当前状态触发事件下一状态关联动作预订单前台确认或渠道确认已确认锁房Blocked Room已确认客人到店办理入住已入住释放预分房房态变为在住已入住早于计划时间离店已离店生成账单并结账已确认超时未到店未到店NoShow按规则收取首晚房费已确认客人主动取消已取消释放锁房算取消违约金已入住客户申请提前退房提前离店调整账单释放房态状态机里特别容易漏的是“免房”和“锁房”。免房指停用房态不参与售卖锁房是保留房态给某个预订。如果概要设计里只有订单状态而没有房态联动开发出来的系统大概率会出现“房间已经订出去但房态还是空房”的翻车现场。所以我会在概要设计里明确任何预订确认操作必须调用房态锁定接口任何入住操作必须把房态改为在住。2.4 数据库设计概要设计里 ER 图必须落到表关系概要设计阶段不需要把每个表的每个字段都列出来但必须画出核心实体之间的关系。酒店管理系统的核心实体主要有房型、房间、价格计划、订单、订单明细、账务流水、客人档案、操作日志。这几张表的关系决定了业务规则能不能成立。比如“价格计划”和“订单”必须通过“订单明细”关联不能直接把价格快照写在订单主表上。为什么因为一个订单可能包含多晚住宿每晚的价格可能不同而且预订时和入住时的价格计划可能调整。如果概要设计不明确这个一对多关系开发时就会为了省几张表把数据压平导致后面改价困难。我一般用如下 ER 要点表格来表达表关系而不是放完整 SQL。实体关系对方实体说明房型1 : N房间一个房型对应多个房间价格计划1 : N订单明细一个价格计划被多个订单明细引用订单1 : N订单明细订单明细记录每晚房价与杂费订单1 : N账务流水所有收款、退款、挂账记入流水客人档案1 : N订单一个客人可有多笔历史订单操作日志N : 1订单关键操作必须留痕概要设计里还需要定义核心字段的约束走向比如“订单金额必须等于所有订单明细金额之和”“已入离店订单不允许删除只允许冲销”。这些业务约束写进设计文档比写进代码更早被评审发现。数据库设计的最终交付物是 ER 图和以上表关系清单不需要给建表 SQL那会拖慢评审节奏。2.5 接口设计内部模块与外部集成的边界概要设计里的接口清单不需要细化到字段但需要把接口方向、触发时机、超时阈值、异常处理方式定清楚。很多团队到详细设计阶段才发现接口定义得含糊导致前端、后端、第三方各做各的。我建议在概要设计阶段用一张接口登记表覆盖所有边界交互。接口名称方向触发时机超时/异常策略预订创建接口外部渠道 - 系统渠道推送新订单100ms 内返回订单号失败返回可重试错误码房态查询接口系统 - 外部渠道渠道查询可用房返回房型等级而非具体房号公安上传接口系统 - 公安平台入住登记后触发300ms 超时失败进入重试队列并人为告警支付预授权接口系统 - 支付网关入住登记或预订时发出预授权后必须等待异步回调最长 2 分钟夜审批量入账接口系统内部模块每日凌晨 2 点事务性批量操作失败自动回滚接口设计在概要设计阶段还要明确“谁调用谁”。我常见到酒店系统里前台模块直接调用财务模块的数据库表这在概要设计阶段就必须禁止。所有跨模块的数据访问统一走服务接口底层表不允许跨库直查。这样后续分库拆分、性能优化才有空间。3. 酒店管理系统和客户关系管理系统的区别数据该放在哪一侧如果你负责的酒店集团已经有独立 CRM 系统概要设计文档里必须花一整章讲清 PMS 与 CRM 的边界。很多团队把“客户关系管理”功能直接塞进酒店管理系统结果系统又重又乱。实际上两者的产品逻辑和数据重心有明显差异不能在概要设计里含糊带过。3.1 产品逻辑差异管理系统管过程CRM管经营酒店管理系统PMS的核心任务是管理“从预订到退房的交易过程”它关注订单状态、房态、账务、夜审数据实时性强错误容忍度低。CRM 系统关注客户长期价值比如会员等级、积分、偏好、消费频次、营销活动效果它的数据可以接受一定延迟但不允许丢失客户画像。用一个表格可以更清楚地表达差异。对比维度酒店管理系统PMS客户关系管理系统CRM核心对象订单、房间、账单会员、客户档案、营销活动数据新鲜度秒级实时分钟级甚至 T1 可接受可靠性要求极高影响对客服务高影响营销决策生命周期单次入住过程客户全生命周期典型操作办理入住、夜审、离店结账会员注册、积分调整、券核销在概要设计文档里建议把这两个系统的边界画成两个独立“泳道”中间用事件连接而不是画成一个大系统。这样做的好处是如果酒店后续要接入集团会员中心现有 PMS 不需要大改。3.2 客史、会员、营销数据的归属判定到底哪些数据应该存在 PMS哪些应该存 CRM我一般按三个规则判断谁的修改频率高谁负责谁产生数据谁消费数据数据的实时性要求决定归属数据是否有跨业务共享价值。例如“客人的手机号”在 PMS 和 CRM 都有但手机号变更通常由客户在 C 端自助修改所以主数据应该放在 CRMPMS 通过接口同步。而“在住状态”是 PMS 实时产生的CRM 只能订阅不能修改。下面给出一个典型的数据归属表实际项目中可直接参考。数据项主数据归属另一侧如何使用同步方式客人姓名、证件号PMSCRM 只读入住登记后事件推送手机号、邮箱CRMPMS 用于订单通知CRM 变更后调用 PMS 接口更新会员等级与积分CRMPMS 展示并支持抵扣实时查询 本地缓存客史偏好CRMPMS 入住单展示CRM 推送偏好快照订单与消费明细PMSCRM 做消费分析离店后异步推送营销活动与券CRMPMS 核销券核销结果实时回调 CRM这个表要尽量在概要设计阶段定下来否则开发时会反复出现“哪个系统是权威数据源”的撕扯。一旦确定 CRM 是会员主表PMS 就不能直改会员等级必须通过接口。3.3 集成方案主数据统一与事件同步确定了数据归属后概要设计还需要给出集成方案。常见做法是 PMS 内部维护一个“客户临时档案”只保存本次入住必需信息CRM 通过消息队列订阅 PMS 的入住、离店、消费事件更新客户模型。反过来CRM 的会员信息变更通过接口实时推送到 PMS 缓存并在预订单中展示。这里要注意一个细节PMS 发往 CRM 的事件必须包含一个全局唯一客户标识比如手机号或统一客号否则 CRM 不知道这是同一个客人。很多酒店集团有多个门店每个门店 PMS 独立但客人在不同门店入住就需要统一客号。概要设计里要定义一个“主索引生成规则”根据证件类型证件号生成不可变的全局 ID所有系统共享这个 ID。如果这一步不做后面做会员合并的巨大工作量就是本来可以避免的。还要考虑断网场景。酒店前台网络故障时PMS 必须能继续办入住会员信息可以读取本地缓存。因此集成方案中需要有一份“本地落库”设计PMS 定期全量同步 CRM 会员数据到本地表增量变更实时更新。这个设计如果漏了会出现“网络一抖客人没法入住”的尴尬。4. 概要设计文档避坑5 个让项目翻车的细节以下问题我几乎在每个酒店管理系统概要设计评审里都会看到写出来供你对照自己的文档检查。4.1 现象文档写成了功能列表评审变成“过一遍”很多概要设计的正文就是“支持预订”“支持入住”“支持退房”这样的清单。评审会上大家念一遍没人发现问题。原因是文档没有按场景组织缺少“谁触发、数据怎么变、失败怎么办”。解决方法是每个功能描述都采用“角色 前置条件 正常流程 异常分支 后置条件”的结构。例如“预订”要写明前台或渠道创建预订单前置条件是所选房型在日期内有可售房间正常流程是锁房并生成确认号异常分支是锁房失败必须提示“房态不足”后置条件是订单进入已确认状态同时生成一条客人档案关联。4.2 现象状态机缺了“免房”“锁房”前台乱套只画订单状态不画房态状态开发完成后会出现“房间被预订但房态显示干净空房导致重复售卖”。原因是概要设计没有建立订单状态与房态状态的联动矩阵。解决方法是增加一张房态状态机表并明确预订确认时修改房态为“预分房”入住时改为“在住”离店后改为“脏房”清扫后改为“干净房”检查后改为“空房-干净”。同时在概要设计里写明免房Out of Order可以在任意状态被设置设置后该房间不再出现在可售列表。4.3 现象房价类型和订单价格脱节文档里写了订单表有“房价”字段但没有说明这个价格从哪来。上线后前台经常遇到“订单显示协议价结账时变成门市价”的神仙问题。原因是价格计划Rate Plan没有纳入设计或者订单没有引用价格计划。解决方法是建立价格计划主表包含门市价、协议价、含早价、连住价、汇率订单明细表必须引用价格计划 ID并快照销价、含税标识、币种。任何手工改价必须在明细表留一张价格变更记录并记录操作人、原因、原价、新价。4.4 现象接口定义到字段名才评审改起来伤筋动骨接口清单在概要设计里一字不写排期时才开始定字段结果发现 OTA 返回的订单号结构不一致、支付回调缺少签名这些大问题到联调才暴露。原因是概要设计没有定义接口层面的“契约骨架”。解决方法是接口清单在概要设计阶段必须包含接口名、调用方向、主要参数对象如订单对象、支付结果对象、超时阈值、错误码分段规则。不需要每个字段名但必须定义出一个“最小可用接口契约”留出字段扩展位比如在订单对象中允许扩展自定义字段。4.5 现象把概要设计和详细设计混在一本 200 页文档里一份文档同时写架构、表结构、页面原型、接口字段、测试用例导致评审时没人看得完也看不见重点。原因是管理者以为“写得越多越安全”实际破坏了文档的结构。解决方法是概要设计控制在 50-80 页聚焦业务架构、系统边界、模块划分、核心状态机、关键表关系与接口清单详细设计按模块拆成多个附录每个附录内部引用概要设计的章节编号例如“请参照概要设计 3.2 节本附录给出订单表 DDL”。这样评审时评审者只需要看概要设计就可以提方向性问题细节问题留给详细设计评审。5. 用场景脚本验证概要设计不写代码也能自检写完整份概要设计后不要急着交评审先自己用业务场景走查一遍。我常用一个做法把一年里最容易出问题的三个场景写成脚本逐条对照文档里的数据流和状态机看能不能闭环。场景一散客通过 OTA 下单后到店办理入住中途续住一晚最后离店结账。对照检查OTA 订单进入 PMS 时状态是“预订单”确认后是否锁定房间客人到店时是否能凭确认号查到订单并转成入住续住时是否触发新的订单明细和房价快照离店时账单是否包含每晚房费和餐饮杂费支付状态是否从预授权转为收款。任何一个环节找不到对应章节就说明文档缺内容。场景二协议单位月结。对照检查协议单位 A 在 7 月入住 10 间夜所有账单都挂账到 A 公司应收账户月初生成应收汇总向 A 公司开票A 公司打款后核销应收。这个场景最容易发现财务模块是否与前台订单模块解耦如果挂账逻辑写在订单表里那这里必然出问题。场景三维修房流转。对照检查客房报修后房态变为 OOS且不能参与售卖维修完成清零变为“脏房”清洁后变为“空房-干净”检查后变为可售。还要检查 OOS 房是否在夜审统计中被排除在可售房总数之外。每走完一个场景把缺失项补进概要设计。这个方法我用了很多年总能抓到三五个漏掉的分支。有一次我漏了“提前离店时的未住晚数退款”分支上线后财务每天手工调账这就是典型的概要设计不严导致的返工。现在我会固执地在文档里给每一个状态转换画一张表并标注“从哪个状态来、到哪个状态去、有哪些非正常路径”。希望这个习惯也能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 9:34:14 · 阅读 1.2k 酒店管理系统概要设计：边界、数据流与接口实战
简介这是一份酒店管理系统概要设计说明文档面向软件开发人员、项目评审员及测试人员用于在详细设计与编码前明确系统的处理流程、功能分配、模块结构、接口关系和数据结构设计。文档以顾客就餐管理、顾客住宿管理、用户信息管理和数据库信息管理四大业务为主线逐项说明各模块的输入、处理过程与输出并覆盖总体设计、运行环境、基本设计概念、接口设计、运行设计、系统出错处理与维护设计等内容同时给出了从用户登录、密码验证、权限判断到具体业务操作的系统活动图。资源包为单份doc文档大小约206KB内容按标准概要设计说明书章节编排目录结构清晰便于快速定位到相应设计部分。目前已有45人学习/下载适合计算机相关专业课程设计、毕业设计或中小型酒店管理系统项目前期参考也可作为梳理同类系统架构与编写设计说明书的实用范例。1. 酒店管理系统概要设计说明先想清楚再写代码拿到一个“酒店管理系统概要设计说明.doc”大多数人第一反应是“又要写一份没人看的文档”。但如果你接过真实项目就知道概要设计是酒店管理系统开发里最容易返工、也最能省钱的环节。它要回答三个问题系统给谁用、模块怎么分、关键数据怎么流转。这份文档解决了“需求到代码之间的鸿沟”适合产品经理、项目经理、后端开发、甚至刚入职的初级工程师去读它能让你在写第一行代码前就能发现 80% 的设计缺陷。很多项目翻车不是因为码农水平不够而是概要设计里漏了免房、锁房、汇率、夜审这些业务细节。2. 概要设计文档怎么组织从边界到接口的五个核心段落一份能落地的酒店管理系统概要设计我一般建议按五个段落写系统边界、模块划分、数据流、数据库关系、接口约定。这五个段落有先后顺序边界不清会导致模块划分反复模块没定会导致数据流画不出来数据流没定会导致表结构瞎设计。下面逐个说明每个段落里到底要放什么以及需要做到什么粒度。2.1 用上下文图界定系统边界别急着画功能树很多概要设计第一页就是“系统管理模块、客房管理模块……”这是本末倒置。你应该先画一张上下文图把系统放在中间然后列出所有外部参与者和外部系统。对于酒店管理系统外部参与者通常有前台接待、宾客、客房服务员、财务人员、餐饮部员工、店长外部系统通常有OTA 渠道携程、美团、Booking、PMS 接口、公安登记上传平台、支付网关、短信服务商、税控系统、会员 CRM 系统。上下文图的价值在于它把“哪些数据是本系统内部职责”“哪些数据需要外部协作”一次性说清。比如公安登记上传如果概要设计阶段没写明由谁提供数据、何时触发上传、失败后怎么补偿开发时就会出现“前台办完入住公安系统一直查不到记录”的严重事故。我通常会在文档里用一个表格列出外部交互点如下。外部系统/参与者数据方向触发时机失败处理OTA 渠道入库订单与出库房态、价格用户下单/确认时订单状态标记为“待确认”定时同步公安上传平台出库客人实名信息入住登记完成后 10 秒内本地记录上传状态支持手动重传支付网关出库支付请求与回调预授权/收款时回调幂等订单支付状态以回调为准短信服务商出库验证码、订单确认短信预订成功/入住提醒发送失败不阻塞主流程记录日志CRM 系统出入库客史、会员、营销数据入住离店事件发生后发送失败进入重试队列日终对账边界确定后再画功能树就不容易跑偏。功能树里的每个功能都要能回溯到某个外部交互需求否则就是多余功能。2.2 模块划分高内聚低耦合的标准与粒度酒店管理系统常见的模块划分是前台管理、客房中心、餐饮 POS、财务应收、会员与 CRM、基础数据、系统管理。但很多人划分模块只看“功能分区”导致前台模块里塞了房价设置财务模块里又塞了订单冲销。我建议用三个标准来判断一个功能该属于哪个模块数据归属、变更频率、使用角色。数据归属指这个功能主要读写哪一组表。比如“房价管理”虽然前台常用但房价表的维护者是收益管理员变更频繁且影响全局所以归到基础数据模块更合适。“订单冲销”读写财务账务表归财务应收。变更频率上低频变更的配置类功能集中在基础数据高频交易类集中在业务模块。使用角色上同一个业务动作如果跨两个角色就要拆两个接口而不是一个页面让两个角色共用。下面是一个模块职责表可以在概要设计里直接照抄并裁剪。模块职责摘要核心数据对象依赖其他模块前台管理预订、入住、换房、退房、修改房价订单、房态、客人档案依赖于基础数据中的房价、房型客房中心房态清扫、维修申报、布草管理房态日志、客房任务读取前台入住数据餐饮 POS点菜、结账、厨打餐饮订单、支付流水依赖财务应收做汇总财务应收入账、离店结账、夜审、挂账、冲销账务流水、账单依赖前台订单和餐饮订单会员与 CRM会员注册、积分、券、客史分析会员档案、积分明细订阅订单和消费事件基础数据房型、房价计划、税率、杂费项目价格计划、商品档案无模块划分的粒度以“一个开发组 3-5 人两周能交付迭代”为参考。如果你把一个模块拆到 20 张表、10 个人开发那就要继续往详细设计推进不要停在概要设计。2.3 数据流从预订到入住、离店的三个状态机概要设计里最容易画错的是状态机。很多文档只有一个“订单状态”未确认、已确认、已入住、已离店。但酒店管理的实际业务远比这个复杂。我习惯把状态机拆成三个订单状态机、房态状态机、支付状态机。三个状态机互相联动但不混在一个状态字段里。订单状态机至少要包含预订单、已确认、已入住、已离店、已取消、未到店NoShow、提前离店、作废。房态状态机至少包含空房Vacant、干净Clean、脏房Dirty、检查中Inspected、维修房OOS、预分房Blocked、在住Occupied。支付状态机包含未支付、预授权、已收款、部分收款、挂账、退款中、已退款。下面用表格描述核心的订单状态迁移。当前状态触发事件下一状态关联动作预订单前台确认或渠道确认已确认锁房Blocked Room已确认客人到店办理入住已入住释放预分房房态变为在住已入住早于计划时间离店已离店生成账单并结账已确认超时未到店未到店NoShow按规则收取首晚房费已确认客人主动取消已取消释放锁房算取消违约金已入住客户申请提前退房提前离店调整账单释放房态状态机里特别容易漏的是“免房”和“锁房”。免房指停用房态不参与售卖锁房是保留房态给某个预订。如果概要设计里只有订单状态而没有房态联动开发出来的系统大概率会出现“房间已经订出去但房态还是空房”的翻车现场。所以我会在概要设计里明确任何预订确认操作必须调用房态锁定接口任何入住操作必须把房态改为在住。2.4 数据库设计概要设计里 ER 图必须落到表关系概要设计阶段不需要把每个表的每个字段都列出来但必须画出核心实体之间的关系。酒店管理系统的核心实体主要有房型、房间、价格计划、订单、订单明细、账务流水、客人档案、操作日志。这几张表的关系决定了业务规则能不能成立。比如“价格计划”和“订单”必须通过“订单明细”关联不能直接把价格快照写在订单主表上。为什么因为一个订单可能包含多晚住宿每晚的价格可能不同而且预订时和入住时的价格计划可能调整。如果概要设计不明确这个一对多关系开发时就会为了省几张表把数据压平导致后面改价困难。我一般用如下 ER 要点表格来表达表关系而不是放完整 SQL。实体关系对方实体说明房型1 : N房间一个房型对应多个房间价格计划1 : N订单明细一个价格计划被多个订单明细引用订单1 : N订单明细订单明细记录每晚房价与杂费订单1 : N账务流水所有收款、退款、挂账记入流水客人档案1 : N订单一个客人可有多笔历史订单操作日志N : 1订单关键操作必须留痕概要设计里还需要定义核心字段的约束走向比如“订单金额必须等于所有订单明细金额之和”“已入离店订单不允许删除只允许冲销”。这些业务约束写进设计文档比写进代码更早被评审发现。数据库设计的最终交付物是 ER 图和以上表关系清单不需要给建表 SQL那会拖慢评审节奏。2.5 接口设计内部模块与外部集成的边界概要设计里的接口清单不需要细化到字段但需要把接口方向、触发时机、超时阈值、异常处理方式定清楚。很多团队到详细设计阶段才发现接口定义得含糊导致前端、后端、第三方各做各的。我建议在概要设计阶段用一张接口登记表覆盖所有边界交互。接口名称方向触发时机超时/异常策略预订创建接口外部渠道 - 系统渠道推送新订单100ms 内返回订单号失败返回可重试错误码房态查询接口系统 - 外部渠道渠道查询可用房返回房型等级而非具体房号公安上传接口系统 - 公安平台入住登记后触发300ms 超时失败进入重试队列并人为告警支付预授权接口系统 - 支付网关入住登记或预订时发出预授权后必须等待异步回调最长 2 分钟夜审批量入账接口系统内部模块每日凌晨 2 点事务性批量操作失败自动回滚接口设计在概要设计阶段还要明确“谁调用谁”。我常见到酒店系统里前台模块直接调用财务模块的数据库表这在概要设计阶段就必须禁止。所有跨模块的数据访问统一走服务接口底层表不允许跨库直查。这样后续分库拆分、性能优化才有空间。3. 酒店管理系统和客户关系管理系统的区别数据该放在哪一侧如果你负责的酒店集团已经有独立 CRM 系统概要设计文档里必须花一整章讲清 PMS 与 CRM 的边界。很多团队把“客户关系管理”功能直接塞进酒店管理系统结果系统又重又乱。实际上两者的产品逻辑和数据重心有明显差异不能在概要设计里含糊带过。3.1 产品逻辑差异管理系统管过程CRM管经营酒店管理系统PMS的核心任务是管理“从预订到退房的交易过程”它关注订单状态、房态、账务、夜审数据实时性强错误容忍度低。CRM 系统关注客户长期价值比如会员等级、积分、偏好、消费频次、营销活动效果它的数据可以接受一定延迟但不允许丢失客户画像。用一个表格可以更清楚地表达差异。对比维度酒店管理系统PMS客户关系管理系统CRM核心对象订单、房间、账单会员、客户档案、营销活动数据新鲜度秒级实时分钟级甚至 T1 可接受可靠性要求极高影响对客服务高影响营销决策生命周期单次入住过程客户全生命周期典型操作办理入住、夜审、离店结账会员注册、积分调整、券核销在概要设计文档里建议把这两个系统的边界画成两个独立“泳道”中间用事件连接而不是画成一个大系统。这样做的好处是如果酒店后续要接入集团会员中心现有 PMS 不需要大改。3.2 客史、会员、营销数据的归属判定到底哪些数据应该存在 PMS哪些应该存 CRM我一般按三个规则判断谁的修改频率高谁负责谁产生数据谁消费数据数据的实时性要求决定归属数据是否有跨业务共享价值。例如“客人的手机号”在 PMS 和 CRM 都有但手机号变更通常由客户在 C 端自助修改所以主数据应该放在 CRMPMS 通过接口同步。而“在住状态”是 PMS 实时产生的CRM 只能订阅不能修改。下面给出一个典型的数据归属表实际项目中可直接参考。数据项主数据归属另一侧如何使用同步方式客人姓名、证件号PMSCRM 只读入住登记后事件推送手机号、邮箱CRMPMS 用于订单通知CRM 变更后调用 PMS 接口更新会员等级与积分CRMPMS 展示并支持抵扣实时查询 本地缓存客史偏好CRMPMS 入住单展示CRM 推送偏好快照订单与消费明细PMSCRM 做消费分析离店后异步推送营销活动与券CRMPMS 核销券核销结果实时回调 CRM这个表要尽量在概要设计阶段定下来否则开发时会反复出现“哪个系统是权威数据源”的撕扯。一旦确定 CRM 是会员主表PMS 就不能直改会员等级必须通过接口。3.3 集成方案主数据统一与事件同步确定了数据归属后概要设计还需要给出集成方案。常见做法是 PMS 内部维护一个“客户临时档案”只保存本次入住必需信息CRM 通过消息队列订阅 PMS 的入住、离店、消费事件更新客户模型。反过来CRM 的会员信息变更通过接口实时推送到 PMS 缓存并在预订单中展示。这里要注意一个细节PMS 发往 CRM 的事件必须包含一个全局唯一客户标识比如手机号或统一客号否则 CRM 不知道这是同一个客人。很多酒店集团有多个门店每个门店 PMS 独立但客人在不同门店入住就需要统一客号。概要设计里要定义一个“主索引生成规则”根据证件类型证件号生成不可变的全局 ID所有系统共享这个 ID。如果这一步不做后面做会员合并的巨大工作量就是本来可以避免的。还要考虑断网场景。酒店前台网络故障时PMS 必须能继续办入住会员信息可以读取本地缓存。因此集成方案中需要有一份“本地落库”设计PMS 定期全量同步 CRM 会员数据到本地表增量变更实时更新。这个设计如果漏了会出现“网络一抖客人没法入住”的尴尬。4. 概要设计文档避坑5 个让项目翻车的细节以下问题我几乎在每个酒店管理系统概要设计评审里都会看到写出来供你对照自己的文档检查。4.1 现象文档写成了功能列表评审变成“过一遍”很多概要设计的正文就是“支持预订”“支持入住”“支持退房”这样的清单。评审会上大家念一遍没人发现问题。原因是文档没有按场景组织缺少“谁触发、数据怎么变、失败怎么办”。解决方法是每个功能描述都采用“角色 前置条件 正常流程 异常分支 后置条件”的结构。例如“预订”要写明前台或渠道创建预订单前置条件是所选房型在日期内有可售房间正常流程是锁房并生成确认号异常分支是锁房失败必须提示“房态不足”后置条件是订单进入已确认状态同时生成一条客人档案关联。4.2 现象状态机缺了“免房”“锁房”前台乱套只画订单状态不画房态状态开发完成后会出现“房间被预订但房态显示干净空房导致重复售卖”。原因是概要设计没有建立订单状态与房态状态的联动矩阵。解决方法是增加一张房态状态机表并明确预订确认时修改房态为“预分房”入住时改为“在住”离店后改为“脏房”清扫后改为“干净房”检查后改为“空房-干净”。同时在概要设计里写明免房Out of Order可以在任意状态被设置设置后该房间不再出现在可售列表。4.3 现象房价类型和订单价格脱节文档里写了订单表有“房价”字段但没有说明这个价格从哪来。上线后前台经常遇到“订单显示协议价结账时变成门市价”的神仙问题。原因是价格计划Rate Plan没有纳入设计或者订单没有引用价格计划。解决方法是建立价格计划主表包含门市价、协议价、含早价、连住价、汇率订单明细表必须引用价格计划 ID并快照销价、含税标识、币种。任何手工改价必须在明细表留一张价格变更记录并记录操作人、原因、原价、新价。4.4 现象接口定义到字段名才评审改起来伤筋动骨接口清单在概要设计里一字不写排期时才开始定字段结果发现 OTA 返回的订单号结构不一致、支付回调缺少签名这些大问题到联调才暴露。原因是概要设计没有定义接口层面的“契约骨架”。解决方法是接口清单在概要设计阶段必须包含接口名、调用方向、主要参数对象如订单对象、支付结果对象、超时阈值、错误码分段规则。不需要每个字段名但必须定义出一个“最小可用接口契约”留出字段扩展位比如在订单对象中允许扩展自定义字段。4.5 现象把概要设计和详细设计混在一本 200 页文档里一份文档同时写架构、表结构、页面原型、接口字段、测试用例导致评审时没人看得完也看不见重点。原因是管理者以为“写得越多越安全”实际破坏了文档的结构。解决方法是概要设计控制在 50-80 页聚焦业务架构、系统边界、模块划分、核心状态机、关键表关系与接口清单详细设计按模块拆成多个附录每个附录内部引用概要设计的章节编号例如“请参照概要设计 3.2 节本附录给出订单表 DDL”。这样评审时评审者只需要看概要设计就可以提方向性问题细节问题留给详细设计评审。5. 用场景脚本验证概要设计不写代码也能自检写完整份概要设计后不要急着交评审先自己用业务场景走查一遍。我常用一个做法把一年里最容易出问题的三个场景写成脚本逐条对照文档里的数据流和状态机看能不能闭环。场景一散客通过 OTA 下单后到店办理入住中途续住一晚最后离店结账。对照检查OTA 订单进入 PMS 时状态是“预订单”确认后是否锁定房间客人到店时是否能凭确认号查到订单并转成入住续住时是否触发新的订单明细和房价快照离店时账单是否包含每晚房费和餐饮杂费支付状态是否从预授权转为收款。任何一个环节找不到对应章节就说明文档缺内容。场景二协议单位月结。对照检查协议单位 A 在 7 月入住 10 间夜所有账单都挂账到 A 公司应收账户月初生成应收汇总向 A 公司开票A 公司打款后核销应收。这个场景最容易发现财务模块是否与前台订单模块解耦如果挂账逻辑写在订单表里那这里必然出问题。场景三维修房流转。对照检查客房报修后房态变为 OOS且不能参与售卖维修完成清零变为“脏房”清洁后变为“空房-干净”检查后变为可售。还要检查 OOS 房是否在夜审统计中被排除在可售房总数之外。每走完一个场景把缺失项补进概要设计。这个方法我用了很多年总能抓到三五个漏掉的分支。有一次我漏了“提前离店时的未住晚数退款”分支上线后财务每天手工调账这就是典型的概要设计不严导致的返工。现在我会固执地在文档里给每一个状态转换画一张表并标注“从哪个状态来、到哪个状态去、有哪些非正常路径”。希望这个习惯也能帮到你。本文还有配套的精品资源点击获取