1. 医疗App产品全景与架构总览
医疗App不是普通消费类应用的简单变体。它同时面对生命健康、强监管、多角色协作和高数据敏感度四重约束，这决定了它的产品形态与系统架构必须从一开始就按“业务—合规—技术”三条线并行设计。本章作为课程开篇，先建立一张全景地图：医疗行业到底特殊在哪里，主流产品分为哪几类，业务工程与产品架构是什么关系，以及贯穿全课程的实战项目将如何展开。
一、医疗行业的四个特殊性
理解医疗App，先要理解它和电商、社交类App的本质差异。这些差异不是“行业背景介绍”，而是直接决定架构选型的约束条件。
- 强监管与资质门槛。挂号、问诊、售药分别对应不同的合规要求。互联网诊疗需要依托实体医疗机构，医师需实名认证并具备执业资质；药品销售需区分处方药与非处方药，处方药不得直接面向公众展示和销售。这意味着系统里“谁能做什么”不是产品经理随意定义的，而是由资质数据模型和审核流程强约束的。
- 数据敏感度极高。病历、处方、检验报告、身份信息属于敏感个人信息，传输必须加密，存储需脱敏或分级，访问要留痕。架构上不能把医疗数据当普通业务数据随意缓存和日志打印。
- 多角色、多端协同。一个挂号订单背后涉及患者、医生、科室、医院信息系统（HIS）、支付渠道、短信/推送平台。App只是协同链条中的一环，必须与外部系统对接。
- 业务连续性要求高。挂号高峰、问诊并发、支付回调都可能瞬时放量，且医疗场景对“失败可恢复”要求高——一次挂号失败不能让用户重复扣费。
二、四类主流产品的业务特征
医疗App通常可归为四类，它们的核心链路和架构重点各不相同。
| 产品类型 | 核心链路 | 架构重点 |
|---|---|---|
| 挂号预约 | 选医院→选科室→选医生→选号源→支付→取号 | 号源库存一致性、防超卖、与HIS排班同步 |
| 在线问诊 | 选医生→描述病情→支付→图文/视频沟通→开方→购药 | 会话实时性、处方合规、医生排班与接诊状态 |
| 健康管理 | 建档→记录指标→计划→提醒→随访→报告 | 数据模型灵活、长期存储、指标趋势计算 |
| 医药电商 | 选药→加购→下单→审方→支付→配送 | 处方审核、库存、订单状态机、冷链/配送约束 |
实际产品往往是组合形态，例如“问诊+购药”形成闭环，“挂号+健康管理”形成患者长期档案。架构设计时要识别哪些能力可复用，哪些必须按业务隔离。
三、业务工程与产品架构的关系
业务工程关注“业务怎么跑通、规则怎么落地、异常怎么处理”，产品架构关注“系统怎么分层、模块怎么划分、数据怎么流转”。两者不是上下游，而是同一问题的两个视角：业务工程定义需求与规则，产品架构把它们翻译成可扩展、可维护、可合规的系统结构。
举个具体例子。业务工程提出规则：“同一患者同一科室同一天只能挂一个号。”产品架构要把它落成：在挂号服务中增加唯一性校验，用“患者ID+科室ID+就诊日期”作为幂等键，并在数据库层加唯一索引兜底，同时处理并发下的重复提交。规则是业务的，实现是架构的，缺一不可。
四、课程项目贯穿说明
本课程将用一个贯穿项目——“社区医疗综合服务App”作为主线。它包含挂号预约、在线问诊、健康档案、药品下单四个模块，覆盖四类产品形态，便于在后续章节中逐步展开架构设计。
项目采用前后端分离结构：移动端负责交互与本地缓存，网关负责鉴权与限流，业务服务按领域拆分，数据层区分业务库与医疗敏感库。后续章节会依次深入需求建模、领域划分、接口设计、状态机、合规校验、性能与容灾等主题，每一章都在这个项目上落地。
这张全景图把本章四个要点串在一起：左侧是行业约束，中间是产品形态，右侧是架构分层，底部是业务工程与产品架构的双向关系。后续每一章都会从这张图上取一个局部深入，逐步把“社区医疗综合服务App”从概念推进到可落地的设计。