做这套宠物店管理系统其实是在一次接商业外包的活儿时边做边打磨出来的。当时门店的需求挺杂的既要管宠物档案又要管商品库存、会员充值、寄养预约老板还希望员工能通过手机浏览器直接操作不想装一堆桌面客户端。前前后后改了好几版最后定下来用Java SpringBoot SSM这一套体系去落地整条链路从需求梳理到交付部署跑通了也顺手沉淀成了套可复用的项目。这篇就把整个系统的设计思路、技术选型、核心业务拆解、踩坑记录和调试经验一次性讲清楚给打算做同类管理系统的开发者一份能直接抄作业的参考。这套系统本质上是个典型的中小规模业务管理系统核心价值在于把宠物门店的“进销存服务客户”串成一条数字化的线替代传统excel和纸质台账。它不像电商平台那样高并发也不像大数据系统那样重计算它最看重的是业务状态是否清晰、操作是否顺手、数据是否对得上账。正因如此它非常适合拿来练手整套业务系统的开发流程也特别适合那种想系统掌握SpringBoot SSM整合开发的人从建表到接口再到联调一条龙做完你会对整个后端技术栈有个非常扎实的体感。1. 宠物店管理系统的整体设计与功能拆解做管理系统第一步不是写代码而是把业务模块摸清楚。宠物店看起来不大但业务线其实很杂。我梳理下来大致是几大块宠物本身的管理档案、品种、年龄、健康状态、商品的进销存狗粮、猫砂、玩具这些、门店服务洗护美容、寄养、医疗辅助、客户与会员体系充值、积分、消费记录还有最容易被新手忽略的员工权限。系统设计的时候我是按“基础数据-业务流转-报表统计”三层来划分的。1.1 核心需求解析这些模块到底要管什么先讲宠物档案模块。这里面最容易被做成“只增删改查”的表但门店实际使用中档案需要关联到疫苗接种记录、驱虫记录、体重变化曲线。一家正常运营的店每只宠物从第一次进店洗澡开始就应该建档案出生日期、品种、是否绝育、有无过敏史这些信息在后续服务中会高频使用。我在设计时用一张宠物表作为主表再挂了一张健康记录子表每次服务或就诊后员工可以追加记录形成宠物的完整生命周期数据。商品库存管理这块这里的细节比想象中多。宠物食品和药品是有保质期的所以我的库存表里加了批次字段和生产日期。这就意味着同一款狗粮进了两批货系统里要有两条记录售卖的时候按先进先出的原则自动扣减。这个细节很多初版设计都会漏掉结果就是盘库存的时候账死活对不上。这个模块还涉及到供应商信息、采购入库单、退货单得形成一套简单但完整的进销存闭环。会员与充值管理是门店老板最看重的模块直接关系到现金流。常见的储值方案是充500送50、充1000送150。我的设计里充值时生成充value记录并更新会员余额消费时生成消费记录并从余额扣除。积分部分则是按消费金额1:1累计积分可以抵现或兑换商品。这块最需要关注的是并发场景下的余额扣减问题后面讲核心实现的时候我会专门提一下。寄养与预约服务是宠物店区别于普通零售店的核心场景。寄养业务有明确的时间窗口入住时间、预计离店时间、实际离店时间中间还要按天计费。如果超期了怎么自动计算续费金额预约服务则是顾客在小程序或电话预约美容、SPA等门店需要排班和确认。我把预约和寄养拆成两张表避免状态逻辑混在一起实际用下来非常清晰。员工与权限管理这块很多小系统会不做但我坚持每一套交付的系统都加上。因为实际运营里店长、美容师、前台收银员能看和能操作的东西是不一样的。管理员掌握全部权限普通员工能操作业务单据但不能看成本价和利润报表。我用的方案是基于拦截器做简单的RBAC没有引入过于笨重的权限框架对这个体量的系统刚刚好。1.2 角色与使用场景分析谁在用这套系统分析系统之前得先代入真实使用场景搞清楚谁会打开这个系统每个人进来干什么事。超级管理员通常是老板本人。他关注的是整店营收状况、商品毛利、会员储值余额、员工工作量。系统里他要看到的是数据报表和财务视角的信息操作上则是建账号、开权限、做系统配置。店长或主管负责前台整体运营。要处理各种日常审批类操作比如大额折扣、寄养延期确认、采购入库核对。前台收银员使用频率最高。每次结账、充值、预约确认都在这个角色上。他需要的是一个字快。页面按钮要少录入要顺手键盘操作要高效。美容师/护理师主要查看当天的服务排期、宠物档案中是否有过敏史或攻击性备注服务结束后填写服务记录。顾客本人若开启自助端可以查看预约状态、宠物档案、消费记录和余额。我在实际交付中做了一套简单的H5页面挂在公众号菜单里顾客用起来反馈很好。角色的不同决定了界面交互不同也决定了接口粒度不同。前后台分离设计中前台员工作业系统更偏表格化、快速操作顾客端更偏卡片化、清晰展示。这套系统里我把后端接口统一按业务模块划分前端页面完全可以根据不同角色分别组装这样后期扩展新终端时不用重新写接口。1.3 系统边界划定与技术方向选择聊完业务该说说系统边界了。我给这套系统划的边界很明确不做复杂的ERP、不做电商交易、不做跨门店连锁聚焦单店或小规模连锁的核心运营闭环。这么定边界不是因为技术做不了而是因为小店的管理者需要的是低门槛、快速上手功能太复杂反而没人愿意用。技术方向上也因为边界清晰而好选很多单店量级的QPS根本不需要引入分布式组件一台普通云服务器跑SpringBoot完全够用稳定性也足够。2. 技术栈选型与架构设计原理技术选型这块我直接选了Java 8 SpringBoot 2.x Spring SpringMVC MyBatis的组合。这套在业界常被叫做SpringBoot整合SSM本质上是用SpringBoot做项目骨架与自动配置内部承载SpringMVC做Web层、MyBatis做持久层。为什么这么选一句话讲就是SpringBoot让校园或教学场景下的工程化部署简单到极致内置Tomcat打完包丢服务器就能跑MyBatis的SQL手写控制力强适合业务查询复杂、性能要求可控的传统管理系统。2.1 为什么是SpringBoot SSM而不是SpringCloud或MyBatis-Plus这套技术栈组合经常被讨论我主要聊下为什么不选另外两个常见方案。为什么不选SpringCloud微服务宠物店管理系统的业务完全处于单体内可清晰的范畴强行拆微服务带来的成本远多于收益运维复杂度也不适合中小团队。单体应用不是耻辱是工程合理性的体现。为什么不选MyBatis-Plus这个词近几年很流行但我做这类管理系统时更倾向强调原生SQL能力。宠物店系统涉及的表关联、统计报表逻辑比较复杂MyBatis手写SQL让我能精准控制每一处左连接、每一条聚合语句排查问题时直接定位SQL语句即可不用绕一层代码生成逻辑。核心组件在项目里具体分工是这样的SpringBoot项目启动入口、自动化配置核心负责整合一切。它解决了传统SSM项目里最头疼的大量XML配置问题约定大于配置的哲学在这类中小系统上体现得淋漓尽致。SpringMVC请求分发与参数绑定层处理HTTP请求到控制器方法的映射、JSON序列化、视图解析。MyBatis持久层框架通过Mapper接口与XML或注解映射SQL灵活性极高。维护依赖管理工具Maven/Gradle管理所有依赖版本省去到处找jar包的痛苦。2.2 前后端交互架构与数据流转链路这套系统采用前后端分离思想但不完全分离的结构。管理后台用传统的服务端页面模板渲染加Ajax局部刷新顾客端H5页面使用Vue.js通过JSON调用后端接口。这种混合架构其实是根据实际场景调的因为没有必要把所有页面都做成纯前后端分离。收银台页面如果全部依赖前端渲染刷新页面状态丢失是要命的服务端渲染反而更可靠。前端页面发送HTTP请求后请求经SpringMVC的前端控制器分发到对应ControllerController负责参数接收与业务逻辑编排事务边界往往在这里界定。Service层专注于业务规则实现例如库存扣减与订单生成的原子性、会员余额的双重校验。DAO层即MyBatis Mapper负责与数据库交互。响应统一封装为一个泛型Result对象包含状态码、消息与数据三个字段这样前端统一解析也变得轻松。2.3 数据库设计的高频技巧字段设计的细节决定成败这套系统的表结构设计我沉淀了不少有用的经验。比如所有业务表都要有主键、创建时间、更新时间这个听起来是废话但实际项目中统计“本月新增会员数”或“按天查询销售额”时没有创建时间字段就要返工。我再补充几个细节金额字段一律用decimal(10,2)绝不用float。宠物行业的客单价虽然不高但涉及储值余额和折扣计算浮点误差会造成严重的对账问题。逻辑删除字段deleted默认0删除数据时执行update而非物理delete。做活动复盘时客户说“帮我看看去年下架的商品有哪些”一个deleted字段直接搞定。状态字段用tinyint存储以告别语义不明的魔法数字每个字段的注释里都写明0代表什么、1代表什么。比如宠物状态0表示在店1表示已售出2表示已寄养3表示已离店。表之间关系通过逻辑外键关联而非物理外键约束避免在数据修正时被外键锁死。员工误操作把主表数据改了关联表不受约束阻碍修改起来没那么痛苦。3. 核心业务模块与数据库表结构的深度拆解数据库表数量大概在18张左右覆盖了系统全部业务模块。这里挑几张核心表拆开讲直接把这些表的设计逻辑讲透你拿到之后照着理解基本就能把整个系统串起来了。3.1 宠物信息表与健康档案表设计宠物信息表是基础主表核心字段包括宠物名称、品种、性别、年龄段、是否绝育、主人客户ID、体重、健康状态备注、状态字段。这里的核心关联是客户ID一只宠物必须归属一个客户档案这样才能做消费画像和客户关怀回访。健康档案表记录每次的医疗服务或健康检查关联宠物ID、服务类型、诊断内容、用药记录、操作员工。存储上不做过多的表关联在列表展示时按宠物ID把这些记录嵌套返回即可。实际运营中因为宠物不会说话健康记录对于门店的价值极高。顾客换了一家店、换了个城市手机里调出这只宠物的完整健康档案对新店建立信任感特别重要。我在这块特意加了个“档案完整度”百分比的计算逻辑引导员工把每个字段填完整。3.2 商品表、批次库存表与采购入库的逻辑商品表是基础信息表包含商品名、分类、品牌、规格、零售价、会员价、成本价、预警库存值、状态。这里的关键细节是成本价字段必须独立存储且对普通员工不可见。设计原因在于销售毛利计算依赖于成本价但如果所有员工都能看到成本门店内部议价体系会崩掉利润信息一旦透明化管理矛盾非常大。批次库存表是这套进销存的核心字段包括商品ID、批次号、进货价、生产日期、保质期截止日期、库存数量、锁定数量。可用库存等于库存总数减去锁定数量。每次销售出货时SQL按生产日期正序排序优先扣最早批次的数量这就是先进先出原则的落地。采购入库单表记录每次入库操作的供应商、经办人、明细快照。为什么用“明细快照”而不是实时去关联批次表因为商品价格经常波动入库时5元进的一年后批记录可能被后面单据误冲掉。快照机制保证了历史单据永远可追溯审计时直接打开当时的JSON快照即可这就省去了大量联表查询和历史数据修复工作。3.3 会员表、充值记录表与消费明细表的闭环设计会员表的核心字段比常规设计多了一个“剩余积分”和“累计充值金额”。累计充值金额与剩余余额的意义不一样它是会员等级升降级和年度回馈的依据不能通过简单累加消费记录来推断因为退款和过期积分会导致逻辑混乱。这里采用冗余字段存储虽说不满足数据库第三范式但业务查询性能好也免去了每次统计都要大范围聚合的烦恼。充值记录表每条记录包含会员ID、充值金额、赠送金额、实际到账金额、支付方式、操作员工。消费明细表则记录每次消费的订单号、商品明细、折扣明细、支付金额、余额扣减、积分变动。这两张表和会员表形成了完整闭环充值时加余额加累计充值消费时减余额加积分退款时反向回滚。这个闭环如果设计得好对账时一眼就知道哪笔对不上定位异常数据非常高效。3.4 寄养预约表与日历排班的设计要点寄养表的关键字段宠物ID、主人联系电话、入住时间、预计离店时间、实际离店时间、每日费用、预付金额、状态、笼位编号。宠物寄养中笼位资源是有限资源大笼位和小笼位数量固定。我在表里加了笼位编号状态从“空闲”到“占用”的变更操作必须在一个事务里完成防止同一笼位被重复分配。寄养按天计费超期部分需要按规则自动计算这块的实现逻辑我放在Service层用LocalDateTime计算时间差按整天向上取整。预约表相对简单服务项目、期望时间、服务员工、宠物ID、客户手机号、状态。预约难点在服务资源的排重同一美容师同一时段不能接两个预约。我在Service层加了一个并发校验查询该员工该时间段是否有重叠预约如果存在则拒绝创建并返回友好提示。这一步在单店场景下发生冲突的概率很小但一旦发生人工处理相当麻烦所以即使只有1%的概率也要做校验。4. 后端核心实现与关键代码解析代码是系统的骨架我直接把几个核心功能的实现思路放出来。4.1 统一响应格式与全局异常处理所有接口返回统一格式这个是从第一个接口开发时就定下的规范。Result对象包含三个字段code、message、data。前端页面拿到这个对象后先判断code是否为0不为0就显示message提示。成功时code0失败时code为业务错误码。全局异常处理用RestControllerAdvice标注一个类捕获业务异常、参数校验异常和兜底异常分别封装成不同错误码返回。这套统一异常机制的好处是后端代码里不需要到处try-catch。业务逻辑中遇到问题就直接throw一个自定义业务异常全局处理器自动捕获并返回前端。以前写传统管理系统时每个Controller里都要写try-catch再往response里塞错误信息代码又乱又难维护。统一格式化之后后端代码干净很多排查线上问题时看日志头几行就能判断出异常类型。4.2 会员充值与余额扣减的并发安全实现会员余额操作是这套系统里对数据安全要求最高的环节。充值和消费本质上都是一句话在一个事务里先查当前余额再计算新余额最后更新。但如果两个人同时操作就会出问题。比如一个顾客让前台充值的同时伴侣在手机上消费两个请求同时查到余额为1000一个减50变成950一个加200变成1200后提交的覆盖先提交的最终结果只剩1200那50块钱就凭空不见了。解决方式我用了数据库层面的乐观锁在会员表中加一个version字段。更新余额时SQL语句里带上where version #{oldVersion}并且执行update set balance newBalance, version version 1 where id #{id} and version #{oldVersion}。当受影响行数为0时说明并发产生了冲突重新读取最新数据再执行一次业务操作。这里没有用悲观锁的select for update因为锁粒度太大前台高频操作时会影响整体吞吐。乐观锁在单店并发量下完全够用实现也更简单。在研发阶段我专门写了一段模拟代码开启10个线程同时对同一会员执行充值操作每个线程充100元最后校验会员余额是否增加1000。初版不加锁的实现跑完结果是900加了乐观锁之后稳定在1000。建议你们拿到项目后也做一下这个实验对理解并发安全问题很有帮助。4.3 库存扣减与订单生成的事务控制下订单时的事务逻辑涉及两个关键操作写订单明细、扣减库存批次。这里必须保证原子性否则会出现“订单建了但库存没扣”或“库存扣了但订单没建成”的脏数据。实现方式是在Service层方法上标注Transactional把商品信息校验、订单主表插入、订单明细插入、批次库存更新放在同一个事务里。还有一个容易忽略的问题事务里不能包含远程调用或耗时操作。我见过一个案例团队在订单事务里调用短信服务结果短信通道超时整个事务回滚订单没创建成功顾客却收到了扣款短信投诉直接打到老板那边。我这套系统的处理方式是事务内只操作数据库发短信、发通知这类操作全部放到事务提交后通过异步事件触发。Spring的事件机制在这里派上用场事务提交后发布事件监听器异步发送通知既不影响事务一致性也提升了用户体验。4.4 权限拦截器的设计与Session管理系统采用了基于拦截器实现的简单RBAC模型。拦截器继承HandlerInterceptorAdapter在preHandle方法中获取当前请求路径判断当前登录用户是否有该路径对应的权限。权限数据存成两张表角色表、角色权限关联表。登录时把用户的角色信息加载进Session每次请求时拦截器读取Session中的角色权限列表与当前请求路径匹配。数据库里的权限码可以是字符串如pet:add、order:delete、member:refundController方法上通过自定义注解标注所需权限码拦截器通过反射获取注解值做比对。这样做的好处是权限控制和业务逻辑分离新加一个接口需要控制权限时只需在方法上标注注解即可。Session管理这块采用传统HttpSession加Redis的方案。单店场景下直接使用内存Session也没有问题但如果后期要挂小程序或做多端登录就得引入Redis统一存储。我做的是双适配配置文件里给一个开关true走Redis存储Sessionfalse走默认内存Session。部署时按实际需要调整即可。4.5 报表统计模块的SQL优化报表模块是查询密度最高、SQL最复杂的地方。日销售额统计、商品销售排行、会员消费排行、服务项目频次等本质上都是对业务记录表做聚合查询。初版实现中采购大表联查时数据量稍微上来后查询耗时到了两秒多这个体验完全不行。优化做了三件事。第一为高频查询字段建立复合索引例如订单表的创建时间加门店ID组合索引日统计查询直接走索引从全表扫描变成索引范围扫描耗时降到100毫秒内。第二报表数据按月汇总表做预聚合每日凌晨跑定时任务把前一天的数据聚合存储展示上月报表时直接查汇总表不用扫描几十万行明细。第三SQL语句中避免使用select *明确列出所需字段减少IO传输量。报表页面还加了个缓存层同一用户同一条件五分钟内请求相同数据直接走缓存数据库压力瞬间降下来。5. 开发部署全流程与调试经验记录这一节内容全是实战出来的经验项目从零到交付的环节我按时间顺序把关键步骤和踩过的坑整理一遍。5.1 从初始化到跑起来环境搭建的20分钟速通环境清单就是标准Java开发三件套JDK 8、Maven 3.6、MySQL 5.7再加一个开发工具。数据库初始化时我建议直接用项目附带的SQL脚本一次性导入所有表结构和基础数据避免手敲建表语句造成字段遗漏或类型不一致。初始化过程中最容易出问题的两个点一是MySQL连接时区问题二是字符集问题。连接串里必须加上serverTimezoneAsia/Shanghai和useUnicodetruecharacterEncodingutf8否则输入中文变成问号时间字段差8个小时。我见过不少同学卡在这两步折腾半小时都起不来服务其实加上这两个参数就全好了。项目用的是Maven管理依赖SpringBoot的starter依赖会自动带出配套版本。第一次依赖下载时间比较长需要保持网络通畅。启动时直接在项目根目录运行mvn spring-boot:run控制台出现SpringBoot启动成功的图形标签后浏览器访问配置好的后台地址即可看到登录页面。5.2 核心配置文件的逐项说明与坑点总结application.yml文件是SpringBoot项目的配置中心。我逐一说明重点配置项和对应的坑。参数server.port指定项目端口默认我设为8080如果和本机其他服务冲突就往后改到8081或8082。这个问题在多人共用一台开发机时经常遇到改端口是最快的解决方案。参数spring.datasource.url、username、password三项连接本地数据库时本地地址写localhost。如果连远程数据库修改为对应IP即可。这里注意MySQL8.0和5.7的驱动名不同driver-class-name不要搞混否则启动直接报错。参数mybatis.mapper-locations指定Mapper XML文件的位置我统一放在classpath:mapper/*.xml。如果没配置这个MyBatis扫描不到XML文件所有Mapper方法都会报无效绑定异常。参数spring.redis配置在启用Redis Session时需要。不在本地装Redis的场合可以不开启。5.3 真机调试实录三次典型报错从发生到解决的全过程第一个报错是MyBatis的BindingException提示无效绑定。问题根源是Mapper接口和XML文件没有建立映射关系我把接口的包路径改了但忘了改XML中的namespace或者XML文件没有正确扫描到。排查步骤是检查Mapper接口全类名与XML命名空间一致检查mybatis.mapper-locations路径与XML实际位置一致在配置文件里加上mybatis.type-aliases-package并指向实体类包。处理好这三点绑定问题基本不会再有。第二个报错是启动时数据库连接失败。日志提示Unable to connect to the database。直接原因通常不止一个。可能是数据库服务没启动在命令行输入连接命令验证一下可能是用户名密码错误把application.yml里的账号密码和数据库实际账号对照多数情况还是时区或SSL配置问题。连接串额外加上useSSLfalse和allowPublicKeyRetrievaltrue这两个参数能解决80%的连接异常。第三个报错是页面中文乱码。这个场景是环境问题页面显示中文乱码数据库存进去的中文也是乱码。排查下来是三层编码不一致页面本身没有设置UTF-8、数据库表字符集不是utf8mb4、连接串没有带上characterEncodingutf8。我统一把数据库表字符集直接改掉页面的meta标签和服务器响应头都声明UTF-8应用配置文件同时修改三层一致后乱码彻底消失。5.4 部署到云服务器的完整操作流程系统要上线打包部署是最后一公里。打包方式很简单在项目根目录执行mvn clean package -DskipTests就会在target目录生成一个JAR包文件名一般是项目名加版本号。这个JAR包就是包含了Tomcat的完整可运行文件直接扔到服务器。服务器上需要先装好JDK和MySQL数据库。数据库迁移时用命令行执行mysql -u用户名 -p密码 x.sql导入表结构和初始数据。导入成功后启动命令是nohup java -jar app.jar logs.log 21 nohup保证SSH断开后进程不退出。初次启动等待20秒左右用tail -f logs.log查看启动日志看到成功的标志图形后用浏览器访问http://服务器IP:8080。这里有几个运维细节经常会踩坑。一是云服务商的安全组8080端口可能默认没开放要在控制台放行否则本地浏览器死活访问不了。二是服务器防火墙如果开了需要执行firewall-cmd --add-port8080/tcp --permanent放行。三是数据库的bind-address如果是127.0.0.1远程客户端就连不上需要改成实际内网地址或注释掉绑定行。这三个问题排查顺序我大概排了一下实测从超时到排查出最终根因很少超过十分钟。6. 常见问题排查速查表与避坑指南这一部分全部来自真实项目运维中的高频问题排查我整理成速查形式方便排错时快速定位。6.1 速查表启动阶段问题启动阶段常见问题按出现顺序排端口被占用application.yml里换端口或者找出占用进程杀掉。Linux下用netstat -tlnp找出PID再killWindows下用netstat -ano加taskkill。配置数据库连接失败先确认数据库服务在运行再检查用户名密码最后在连接串加useSSLfalse、allowPublicKeyRetrievaltrue。Redis连接失败这个常见。如果没装Redis或者没开Redis服务Session配置启用时就无法连接。不使用时将配置的开关设回false。JAR包打包失败多数是依赖没有下载全。执行mvn clean package时加-e参数打印详细错误信息定位是哪个模块的问题多数通过更新依赖或清理本地仓库缓存解决。6.2 速查表运行阶段问题系统跑起来后问题集中在数据和接口层中文变问号按前文提到的三层编码一致方法排查把连接串、表结构、页面声明全部统一成UTF-8。查询数据慢先看表数据量再看SQL执行计划。用EXPLAIN关键字查看是否走了索引关键是避免全表扫描。高频查询字段必须建立索引。接口返回500错误看日志中Exception堆栈。常见的是空指针、SQL语法错误、类型转换异常。定位方法是从日志里复制出完整异常信息优先定位第一个Caused by行。定时任务没执行检查定时任务的开关配置确认SpringBoot启动类上的EnableScheduling注解已加。再检查服务器时区定时任务按cron表达式执行服务器时区不正确会导致执行时间偏移。6.3 避坑指南我从这套系统开发中总结的10条实操经验数据库连接池建议统一用一个数据源管理工具连接超时配置不要太短否则高峰期频繁重建连接很慢。实体类字段类型必须和数据库字段类型严格对应否则数据传输中产生各种转换错误。金额计算用BigDecimal初始化时必须使用String类型的构造参数。new BigDecimal(0.1)会得到0.1000000000000000055511151231257827这样的值项目里这类低级错误导致过金额差一分钱的对账问题。事务注解默认只在抛出RuntimeException时回滚而自定义业务异常如果是继承Exception的回滚就不会触发。处理方式是把异常体系统一继承RuntimeException或在Transactional上指定rollbackFor并配置为Exception.class。接口参数校验不能全依赖前端后端必须再校验一遍。前端拦截只是提升体验后端校验才是数据安全的底线。用Hibernate Validator注解来做参数校验既能减少代码量又能保证规范。大文件或图片上传要注意临时目录权限Linux服务器上/tmp目录的清理策略可能导致临时文件被清掉报错会很难排查。代码里不能打太多System.out改成统一log记录。线上查问题日志不足会非常痛苦。数据统计模块尽量单独提取一套Service不要直接散落在Controller里职责不清晰后期改动非常痛苦。每次发布新版本前必须备份数据库这个习惯救过我两次一次是误删表数据一次是升级脚本写错导致业务表字段错位。项目根目录写一个详细的README文件把启动方式、默认账号密码、数据库配置步骤写得一清二楚。这个看似最不起眼的步骤实际是交付验收时最容易得到好评的细节。7. 这套系统的扩展与演进方向系统交付之后并不意味着结束二次开发的空间还很大。结合我接触的宠物行业客户需求后续可以从几个方向演进。增加小程序端现在的顾客都是微信一族把查询宠物档案、预约服务、在线充值做成小程序门店客单价会有明显提升。后端接口已经按REST风格设计对接小程序端几乎是无痛扩展。增加连锁门店模式如果门店要开分店目前的单店数据模型就需要调整。增加门店表在商品、订单、宠物档案等表中增加门店ID维度报表按门店透视。只要前期表结构设计时预留了门店ID扩展成本不高。增加智能提醒疫苗接种到期、驱虫时间到期、会员余额不足这些都能做成定时任务加消息推送提升客户体验的同时减轻店员记忆负担。增加IoT设备对接智能猫砂盆、自动喂食器这类设备如果能对接系统就能把宠物的日常状态实时同步给主人这是行业内日益升温的智能化方向。这些都跑通以后原本一个简单的门店管理系统会长成一套围绕宠物生活方式的服务平台商业想象空间大很多。我自己做完这个项目比较深刻的体会是做管理系统不是炫技而是要贴着真实业务走。一个字段的设计、一个状态的流转、一个异常的捕获背后都是实际业务的逻辑在驱动。这个宠物店系统算不上技术多前沿但它是那种“每一个细节都为了老板能看清楚账、员工能少挨骂”的落地方案。如果你正在学Java开发或者准备做类似的管理系统跟着这套项目的表结构和代码思路走一遍你会把整个后端开发链路理解得特别通透。
