云海天狼1. 项目背景与需求分析
学校药店作为校园医疗体系的重要组成部分，承担着为师生提供基础药品和医疗用品的重要职能。传统的手工记录或简单电子表格管理方式已经难以满足现代校园药店的运营需求，特别是在药品效期管理、库存预警、处方审核等关键环节。
我在参与某高校医疗中心信息化改造项目时，发现该校药店存在几个典型痛点：
- 药品效期完全依赖人工检查，曾发生过期药品未被及时发现的情况
- 库存数据更新滞后，常出现急需药品缺货现象
- 处方药销售记录不规范，存在合规风险
- 各类报表统计耗时耗力，影响管理决策效率
基于Spring Boot 3构建的信息管理系统能够有效解决这些问题。Spring Boot 3作为当前Java生态中最主流的应用开发框架，其自动配置、起步依赖等特性特别适合快速构建此类业务系统。与学校现有信息系统（如校园卡系统）的集成也更为便捷。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与架构设计
2.1 核心框架选择
选择Spring Boot 3而非旧版本的主要考虑：
- 对Java 17+的全面支持，能利用Records、Text Blocks等新特性简化代码
- 改进的GraalVM原生镜像支持，未来可考虑编译为原生应用
- 增强的Micrometer指标集成，便于系统监控
- 更现代的依赖管理（Spring Boot Starter 3.0+）
技术栈组成：
- 后端：Spring Boot 3.1 + Spring Data JPA
- 前端：Thymeleaf + Bootstrap 5（考虑学校IT部门技术储备）
- 数据库：MySQL 8.0（与学校统一数据库平台保持一致）
- 安全：Spring Security 6 + 校园统一认证系统对接
2.2 系统架构设计
采用经典的三层架构但有所调整：
code复制表示层 → 业务层 → 数据访问层
↑ ↑
安全控制 缓存层
特别设计：
- 药品效期检查作为独立模块，采用Spring Scheduling实现每日自动扫描
- 库存预警引入规则引擎（Easy Rules），支持多条件复合预警规则
- 处方管理实现工作流引擎（Flowable），规范审核流程
3. 核心功能实现细节
3.1 药品信息管理模块
药品数据模型设计要点：
java复制public record Drug(
@Id String id, // 药品编码（遵循学校编码规范）
String name, // 药品通用名
String specification, // 规格（如"10mg×30片"）
String manufacturer, // 生产厂家
DrugCategory category, // 枚举：处方药/非处方药/医疗器械等
LocalDate productionDate,
int shelfLifeMonths, // 保质期（月）
BigDecimal price,
int stock,
String location // 货架位置编码
) {
public boolean isExpired() {
return productionDate.plusMonths(shelfLifeMonths)
.isBefore(LocalDate.now());
}
}
关键实现技术：
- 使用JPA Auditing自动记录创建/修改时间和操作人
- 自定义Repository实现复杂查询（如临近效期药品查询）
- 采用Blob存储药品图片和说明书扫描件
3.2 库存动态管理
库存变更采用事件溯源模式：
- 任何库存变动（入库、出库、报损）都生成领域事件
- 事件处理器统一更新库存快照
- 实现库存流水永久保存，支持全生命周期追溯
核心库存检查逻辑：
java复制@Scheduled(cron = "0 0 9 * * ?") // 每天上午9点执行
public void checkStock() {
drugRepository.findAll().forEach(drug -> {
if (drug.stock() < threshold) {
alertService.sendStockAlert(drug);
}
if (drug.isNearExpiry(30)) { // 30天内将过期
alertService.sendExpiryAlert(drug);
}
});
}
3.3 处方药销售流程
严格的工作流设计：
- 学生持电子处方（对接校医院HIS系统）扫码
- 系统验证处方有效性（日期、医师、签名）
- 药师二次审核（记录审核人工号）
- 销售完成时扣除库存并生成不可篡改日志
安全控制要点：
- 处方修改需双人复核（Four Eyes Principle）
- 所有操作日志使用HMAC签名
- 敏感数据（如学生病历号）加密存储
4. 系统部署与性能优化
4.1 学校环境特殊考量
根据高校IT基础设施特点，我们采取以下部署方案：
- 容器化部署：使用Docker Compose打包应用+MySQL+Redis
- 资源限制：配置JVM最大堆内存为2GB（学校虚拟机通常配置4-8GB内存）
- 备份策略：每日凌晨全量备份+binlog增量备份
4.2 性能优化实践
针对学校药店特有的访问模式（开学季集中采购，平时访问量低）：
-
多级缓存设计：
- 本地Caffeine缓存热点药品数据（TTL=5分钟）
- Redis集群缓存库存状态（TTL=1分钟）
- 数据库查询添加@Cacheable注解
-
批量操作优化：
java复制@Transactional
public void batchImport(List<Drug> drugs) {
int batchSize = 50;
for (int i = 0; i < drugs.size(); i += batchSize) {
List<Drug> batch = drugs.subList(i, Math.min(i + batchSize, drugs.size()));
drugRepository.saveAll(batch);
entityManager.flush();
entityManager.clear(); // 防止内存溢出
}
}
- 针对校医院网络特点（跨校区专线时有延迟）：
- 启用HTTP/2和Brotli压缩
- 静态资源使用CDN加速
- 配置合理的连接池参数（HikariCP）
5. 实际应用中的经验总结
5.1 数据迁移的教训
从旧系统迁移时遇到的典型问题：
-
药品编码规则不一致（旧系统使用6位数字，新系统要求8位字母数字组合）
- 解决方案：编写迁移脚本统一转换，保留映射表供查询
-
历史效期数据缺失
- 处理方案：对无生产日期的药品默认设置为入库日期前3个月
- 添加"数据不完整"标志，优先消耗这类库存
5.2 用户培训要点
针对学校工作人员（多为非IT背景）的培训经验：
- 药品扫码入库时，必须强制拍摄外包装照片（解决经常漏拍问题）
- 系统界面保留关键字段的纸质单据对应位置提示（如"此处填写与进货单一致的批号"）
- 开发"模拟模式"，允许练习操作而不产生真实数据变更
5.3 扩展性设计
为应对未来可能的需求变化：
- 预留API接口用于与校医院电子病历系统对接
- 药品分类采用组合模式，支持多级分类体系
- 价格策略实现策略模式，便于未来支持医保报销等场景
系统上线6个月后的关键指标改善：
- 过期药品发生率降为0
- 库存周转率提升40%
- 处方审核时间缩短65%
- 月度报表生成时间从3小时降至15分钟
在具体实施时，我强烈建议在开发初期就与校医院药房工作人员建立定期沟通机制。我们最初两周一次的需求确认会后来调整为每周一次，大大减少了返工。例如，最初设计的"库存预警阈值"是全局统一的，实际使用中发现不同药品需要不同阈值（如感冒药和急救药品），这个需求就是在第三次周会上提出的。