2. 项目概述与整体设计思路

2.1 项目概述

最近有个刚学完JavaSE基础的同学问我：不借助Spring Boot、不连MySQL，能不能用纯Java写出一套能跑通的“后端管理系统”？于是我用一个“淘宝风卖鞋后台”的项目做了次完整验证。这套系统本质上是一个基于JavaSE（Java Standard Edition）实现的传统单体业务管理系统，覆盖了商品维护、用户管理、订单流转、库存变动、登录鉴权这些电商后台最常见的业务场景，核心目标是把Java基础语法、面向对象设计、集合框架、I/O流、异常处理、多线程等知识点真正串起来，而不是只停留在“能写练习题”的水平。

整个系统不需要安装任何数据库和服务中间件，数据落地用文件存储完成，启动入口就是一个main方法。但这不代表它是一个玩具项目——分层架构、接口设计、数据校验、幂等控制、扩展预留这些工程化设计思路全部保留。如果你正在学JavaSE，或者刚学完想找一个能放进简历的练手项目，这个选题非常适合你。

2.2 为什么选纯JavaSE，而不是直接上框架

很多初学者会有个误区：既然Spring Boot + MySQL已经是行业标配，为什么还要回头写纯JavaSE管理系统？这个问题我在很多场合被问过，我的回答一直很直接：框架帮你解决的是“接入问题”，但解决不了“理解问题”。

先说结论：纯JavaSE能让你看到一切底层运转逻辑。举几个例子，你用Spring Boot的时候，Service里加个@Transactional注解事务就生效了，但你知道底层是怎么判断连接是否需要回滚的吗？你用MyBatis的时候，Mapper接口没有实现类就能被注入，但你知道JDK动态代理在背后干了什么吗？如果你没写过纯Java的事务控制、没手写过数据访问层，这些框架的“魔法”对你来说就是黑盒。

在卖鞋管理系统的场景里，我刻意用文件存储代替数据库，用自定义Controller代替SpringMVC，用工厂模式手动管理对象创建。这样做的目的有三个：

1. 让数据流转过程完全透明：从用户输入到业务处理再到数据落地，每一步都是可见的代码。
2. 逼着你思考数据结构和算法边界：比如同样是查订单，用ArrayList遍历和用HashMap按订单号索引，性能差距在数据量上来以后非常明显。
3. 降低项目搭建门槛：不依赖Maven仓库、不依赖Spring生态、不依赖外部数据库，克隆代码就能跑，适合教学和面试讲解。

这套管理系统采用的方案不是“退步”，而是一个刻意而为的纯净环境。就像练武功先扎马步，跳过基础直接学套路，看起来学得快，但根基不稳。

2.3 功能边界与角色设计

在正式编码之前，我先定义了系统的业务范围。卖鞋的后端管理系统，核心服务对象是两类人：平台运营人员（管理员）和C端购买用户。既然是“后端管理系统”，我就把重心放在后台管理侧，C端只保留必要的下单和订单查询能力。

系统核心功能模块如下：

权限设计上，我采用最经典的两种角色：管理员拥有全部菜单权限，普通用户只能操作自己的购物车和订单。登录时通过用户对象的role字段进行路由控制，菜单展示用if-else即可，但接口层做了统一校验，避免用户绕过菜单直接调用管理功能。

这个边界划分在实际开发中很有参考意义。很多学生项目把所有功能塞到一个类里，界面、逻辑、数据混在一起，看着能跑，但一加需求就崩。用角色和模块把系统切开以后，每个部分独立演化，这也是后端管理系统设计时最值得学的经验之一。

3. 系统总体架构与核心设计决策

3.1 分层架构：界面层、业务层、数据层

这套卖鞋管理系统的代码组织结构，我采用的是经典三层架构，并且严格遵循“上层依赖下层接口，下层不反向依赖”的原则。这种分层方式在家用服务器上跑非常稳定，也方便后续替换实现。

code复制cn.shoe.admin
├── view          // 界面层：控制台菜单、输入解析
├── controller    // 控制层：接收请求、校验参数、路由分发
├── service       // 业务层：核心业务逻辑处理
├── dao           // 数据访问层：文件读写、序列化操作
├── entity        // 实体层：User、Shoe、Order等POJO
├── util          // 工具类：MD5、IdGenerator、DateUtils
└── main          // 启动入口

每层职责单一：view层只负责拼接字符串显示菜单和处理用户输入，不写任何业务规则；service层只做业务判断和流程编排，不关心数据是怎么存下来的；dao层只做数据的增删改查，不知道“下单需要扣库存”这种业务约束