Service 层在 MVC 里的位置
在常见的 MVC 分层里，Service 夹在 Controller 和数据访问层之间。Controller 负责接请求和回响应，真正的业务判断、数据组合、流程编排通常放在 Service 里。这样做的好处很直接：Controller 不会被业务细节撑得太满，后面想复用一段逻辑也不用复制到多个接口里。
这一层通常怎么组织
先把包结构整理出来。在 net.huawei.hrsys_ssm 下建一个 service 包，专门放业务接口。项目一旦有了明确分层，后面找代码会省很多事，至少不会把所有类都堆在一起。
接着定义接口。这里可以先建 DepartmentService 和 EmployeeService，分别对应部门和员工相关的业务能力。接口先立住，调用方依赖的是能力而不是实现，后面替换实现类、补测试都更顺手。
实现类放到 impl 子包里，比如 DepartmentServiceImpl、EmployeeServiceImpl。这类命名没什么花活，但足够清楚，团队里一眼能看明白谁负责什么。
最后是依赖注入。Service 层一般会通过 @Autowired 注入 Mapper，然后去完成数据库查询、更新之类的操作。这里别把 SQL 或持久层细节往 Controller 里塞，不然分层很快就名存实亡。
测试 Service 层
测试这层不复杂，关键是别跳过。可以新建 TestDepartmentService，自动装配 DepartmentService，再写一个 testFindAllDepartments() 方法去查全部部门数据。跑起来后看控制台输出，基本就能确认这一层是不是按预期工作。
我比较倾向于先把 Service 层的测试跑通，再往上接 Controller。原因很简单：业务问题多数不是出在接口映射，而是出在中间那层的处理逻辑。先把这一层单独验证掉，排查起来会轻松很多。
Service 层的价值不在'多一层'，而在它把业务边界收紧了。逻辑集中后，代码更容易维护，也更容易测试；代价是多写一些接口和实现类，但在 Spring Boot 项目里，这个成本通常是值得的。
