1、为积极响应国家“健康中国2030”战略及老龄化社会发展趋势,抢占医疗健康与养老产业融合发展的千亿级蓝海市场,同时结合公司战略,紧跟集团养老布局,辅助养老业务更快更好的落地。
2、平台功能采用增量式(模块化)开发,先聚焦核心本地生活服务模块落地,再根据社区用户反馈与业务拓展需求逐步迭代升级。核心围绕居民高频生活需求构建服务体系,同时兼顾用户使用便捷性,界面设计遵循简洁直观原则,适配银发用户操作习惯。生活服务方面,整合保洁清洗、家庭维修、医疗陪诊、社区管家四大核心服务,其中保洁清洗模块制定标准化服务流程,提供服务类型筛选、服务人员资质展示、服务时间预约等功能;家庭维修模块覆盖家具家电、水电、管道等常见维修场景,实现故障快速上报、维修师傅精准匹配及服务质量追溯;医疗陪诊模块为老人、病患等群体提供预约挂号、全程陪诊、报告代取等全流程服务;社区管家为平台特色服务,采用自有人员服务模式,用户开通会员后可直接拨打专属管家热线,解决日常生活服务处理代办等各类需求,实现“一个电话全搞定”的便捷体验。
这个项目整体采用的是前后端分离 + 模块化分层架构。前端面向用户端和管理端,后端按业务域拆分为用户、服务、订单、会员、管家、陪诊等模块。技术上我重点关注的是后端业务架构设计,核心目标是让不同服务类型能够复用统一的交易和履约能力,而不是每个模块都单独做一套流程。
在后端设计上,我采用了Controller、Service、Manager、Mapper 这种分层方式。
Controller 负责参数接收和接口出参;
Service 负责业务编排和事务控制;
Manager 负责沉淀通用业务能力,比如订单状态流转、价格计算、履约节点处理;
Mapper 负责数据持久化。
数据库设计上,核心是抽象出一套通用订单模型,主表保存订单基础信息,比如用户、服务类型、预约时间、订单状态、支付状态;扩展表存储各个服务特有字段,例如保洁的面积和服务项、维修的故障描述、陪诊的医院和就诊信息。这样做的好处是:订单主流程统一,服务差异通过扩展字段解耦,后续新增服务类型时不需要重构整套系统。
实现层面,我重点做了三件事:
第一是统一状态机设计。因为保洁、维修、陪诊虽然业务不同,但都会经历“待接单、待确认、待上门、服务中、已完成、已取消”这些阶段。我把状态流转抽象成统一规则,并在代码里限制非法状态跳转,避免出现越级修改状态、重复完单这类问题。
第二是履约流程拆分。项目不是简单下单,而是完整的服务闭环,所以我把履约拆成预约、派单、接单、上门、完成、评价几个节点,每个节点都做操作记录和时间留痕,便于后续做售后追溯和运营分析。
第三是模块解耦和可扩展设计。比如社区管家和普通服务订单的流程不完全一样,我没有硬塞进同一套明细逻辑,而是保留统一订单入口,再通过业务类型分发到不同处理器,类似策略模式。这样后面增加新的养老服务,比如助浴、助餐、代办,也能平滑接入。
项目里比较大的难点,一个是多角色协同,用户、服务人员、管家、平台运营看到的状态和可操作节点都不一样;另一个是服务标准不统一,尤其维修和陪诊这类场景个性化很强。我的处理方式是:主流程标准化,差异化配置下沉到服务模板和扩展字段中,既保证系统统一性,也保留业务灵活性。