## 功能拆分

| 功能                                     | 功能描述                                                     | 居民端 | 门禁端 | 志愿者端 | 管理员端 |
| ---------------------------------------- | ------------------------------------------------------------ | ------ | ------ | -------- | -------- |
| 社区人员进出入                           | 临时访客的进出申请、放行逻辑（待定）。<br />外出返回居民的进社区提前报备；去外地出行前的提前申请。<br />扩展：<br />1. 二维码状态颜色（要和政府健康码颜色保持基本一致）<br />2. 刷脸、刷卡出入<br /><br />**居民**：进出入<br />1. 居民端展示动态二维码，门禁端识别放行<br />2. 门禁端展示动态二维码，居民端识别放行<br />（对于行动不便人群提供固定二维码）<br />**管理员**：查看、管理居民进出入<br />1. 查看人员进出记录<br />2. 设置指定居民进出权限 | √      | √      |          | √        |
| 体温上报                                 | 体温/健康信息上报；健康码收集<br /><br />**居民**：每日上报体温<br />（每天上报时相同信息默认自动填充，不需要重复填写）<br />**管理员**：<br />1. 查看居民体温上报记录<br />2. 异常记录推送提醒 | √      |        |          | √        |
| 日常生活物资的调控（买菜团购、药品购置） | 三种策略：团购、正常购买&秒杀（防超买）、预定<br />物资有限，分配策略很重要（保证每个用户不会总抢不到，也尽量避免总分配给）。<br />扩展：居民互助交流，物资交换（待定）<br /><br />**居民端**：<br />查看生活物资<br />下单<br />取消订单<br />发布求助信息（比如缺少什么物资）<br />**管理员**：<br />发布/修改/删除物资信息，设置每人/每户最多买多少<br />查看当前物资订单状态<br />查看居民需要的物资求助信息，针对性处理（增补物资等），然后将其标记为已处理/已忽略等 | √      |        | √        | √        |

用户账户创建逻辑：

1. 社区预先导入 (1)社区门牌号信息，以及门牌号对应的户主身份信息；(2)临时租户信息；(3)社区流动人员登记信息
2. 用户注册账号，注册后绑定系统中已有户主信息（必要信息：用户的电话号码（方便发送短信以及社区联系），微信号）



系统保证：

1. 某一功能出现问题不影响其他功能
2. 核心功能出现问题要有降级策略，不能完全不可用
3. 用户信息的安全性



更多可以拓展的功能：

1. 大屏展示
2. 与政府健康码信息同步
3. 系统建设后的平滑过渡（从不使用这个系统到推广这个系统）
4. 社区通知模块（管理员可以发布公告，社区居民点开居民端后可以浏览公告信息），也可以定向发布消息（即方便管理员联系社区居民；进一步扩展可以发送短信等）
5. 部分部署（可以只部署需要用到的模块）



## 需要确定的细节

用户是自己注册，还是社区提供账号，或者是社区提供token，用户刷卡实现身份验证？



## 一些需要细想的想法

用户和身份分离：一个用户账号可以绑定多个身份，比如一个社区人员同时可以是志愿者



## 前端系统设计

### 管理员端

### 社区人员端

### 志愿者端

### 门禁端



## 后端模块设计

用户认证模块（用户登录、注册、三方授权登录等）

用户信息模块（用户基本信息<住址，联系方式>）

用户健康状态模块（维护用户的健康状态，与外部系统同步信息）

生活物资模块（维护生活物资商品信息<菜品、药品>）

订单模块（社区人员下单，涉及到秒杀相关，可指定上门派送、自取或者由用户自主选择）

派送模块（）

消息推送模块（系统中出现异常信息，例如系统崩溃，出现体温异常居民等，及时推送管理员）

验证码发送模块（用户注册账户，账号信息变更等）