养老小程序

1、为积极响应国家“健康中国2030”战略及老龄化社会发展趋势，抢占医疗健康与养老产业融合发展的千亿级蓝海市场，同时结合公司战略，紧跟集团养老布局，辅助养老业务更快更好的落地。
2、平台功能采用增量式（模块化）开发，先聚焦核心本地生活服务模块落地，再根据社区用户反馈与业务拓展需求逐步迭代升级。核心围绕居民高频生活需求构建服务体系，同时兼顾用户使用便捷性，界面设计遵循简洁直观原则，适配银发用户操作习惯。生活服务方面，整合保洁清洗、家庭维修、医疗陪诊、社区管家四大核心服务，其中保洁清洗模块制定标准化服务流程，提供服务类型筛选、服务人员资质展示、服务时间预约等功能；家庭维修模块覆盖家具家电、水电、管道等常见维修场景，实现故障快速上报、维修师傅精准匹配及服务质量追溯；医疗陪诊模块为老人、病患等群体提供预约挂号、全程陪诊、报告代取等全流程服务；社区管家为平台特色服务，采用自有人员服务模式，用户开通会员后可直接拨打专属管家热线，解决日常生活服务处理代办等各类需求，实现“一个电话全搞定”的便捷体验。

这个项目整体采用的是前后端分离 + 模块化分层架构。前端面向用户端和管理端，后端按业务域拆分为用户、服务、订单、会员、管家、陪诊等模块。技术上我重点关注的是后端业务架构设计，核心目标是让不同服务类型能够复用统一的交易和履约能力，而不是每个模块都单独做一套流程。
在后端设计上，我采用了Controller、Service、Manager、Mapper 这种分层方式。
Controller 负责参数接收和接口出参；
Service 负责业务编排和事务控制；
Manager 负责沉淀通用业务能力，比如订单状态流转、价格计算、履约节点处理；
Mapper 负责数据持久化。
数据库设计上，核心是抽象出一套通用订单模型，主表保存订单基础信息，比如用户、服务类型、预约时间、订单状态、支付状态；扩展表存储各个服务特有字段，例如保洁的面积和服务项、维修的故障描述、陪诊的医院和就诊信息。这样做的好处是：订单主流程统一，服务差异通过扩展字段解耦，后续新增服务类型时不需要重构整套系统。

实现层面，我重点做了三件事：
第一是统一状态机设计。因为保洁、维修、陪诊虽然业务不同，但都会经历“待接单、待确认、待上门、服务中、已完成、已取消”这些阶段。我把状态流转抽象成统一规则，并在代码里限制非法状态跳转，避免出现越级修改状态、重复完单这类问题。
第二是履约流程拆分。项目不是简单下单，而是完整的服务闭环，所以我把履约拆成预约、派单、接单、上门、完成、评价几个节点，每个节点都做操作记录和时间留痕，便于后续做售后追溯和运营分析。
第三是模块解耦和可扩展设计。比如社区管家和普通服务订单的流程不完全一样，我没有硬塞进同一套明细逻辑，而是保留统一订单入口，再通过业务类型分发到不同处理器，类似策略模式。这样后面增加新的养老服务，比如助浴、助餐、代办，也能平滑接入。

项目里比较大的难点，一个是多角色协同，用户、服务人员、管家、平台运营看到的状态和可操作节点都不一样；另一个是服务标准不统一，尤其维修和陪诊这类场景个性化很强。我的处理方式是：主流程标准化，差异化配置下沉到服务模板和扩展字段中，既保证系统统一性，也保留业务灵活性。