ThinkPHP大型项目目录结构分层实践_Service层与逻辑层目录

Service层只封装可复用、跨Controller的领域行为，比如OrderService::createWithItems()负责库存校验、扣减等，但不处理HTTP状态码、不读Request；参数解析、权限判断等应由中间件或BaseController承担。

Service 层该放什么，不该放什么

Service 层不是“写业务逻辑的地方”这个模糊概念的垃圾桶。它只做一件事：封装可复用、跨 Controller 的领域行为。比如 OrderService::createWithItems() 要负责校验库存、扣减、生成流水、发消息——但不处理 HTTP 状态码、不读 Request 对象、不调 view()。

常见错误是把参数解析、权限判断、日志埋点塞进来。这些该在中间件或 BaseController 里做。Service 一旦开始 input()->get() 或 session()->get()，就说明职责溢出了。

• ✅ 正确：调用 GoodsStockService::decrease()、组装 $orderData、事务内写多张表
• ❌ 错误：从 input() 取参数、手动拼 SQL、返回 json(['code'=>0])
• ⚠️ 注意：App\Service\Payment\AlipayService 这种第三方对接类可以存在，但它必须被上层 Service 组合调用，不能被 Controller 直接 new

Logic 层和 Service 层怎么划清边界

ThinkPHP 官方没定义 Logic 层，所以项目里出现 App\Logic\ 时，大概率是历史包袱或职责混乱的信号。真要分层，建议只保留 Service，并用子命名空间表达语义层级，比如 App\Service\Order\CreationService 和 App\Service\Order\RefundService —— 它们同属 Order 领域，但动作分离。

如果硬要设 Logic 层，唯一合理场景是：同一业务动作中，需桥接多个 Service 并做轻量协调（无状态、无持久化）。例如 OrderLogic::cancelAndRefund() 内部调 OrderService::cancel() + RefundService::apply()，但它自己不查库、不改库、不加事务。

• ✅ 合理：Logic 类只 new Service、调方法、return 结果，方法体不超过 10 行
• ❌ 危险：Logic 类里写 DB 查询、含 if-else 分支逻辑、带事务注解
• ⚠️ 兼容性提示：TP6 的 think-orm 默认不扫描 Logic 命名空间，若用了依赖注入，得手动在 app/provider.php 里加绑定

目录结构怎么避免“越拆越乱”

大型项目最常犯的错，是按技术类型（如 Controller/Model/Service）平铺三级目录，结果一个订单功能散落在 5 个目录下，改个字段要开 8 个文件。应该按业务域垂直切分，再按职责水平分层。

推荐结构：app/Order/Controller/OrderController.php、app/Order/Service/OrderService.php、app/Order/Dto/OrderCreateDto.php、app/Order/Repository/OrderRepository.php。Domain 层（如 app/Order/Domain/Order.php）可选，但一旦引入，就必须禁止 Service 直接 new Model。

• ✅ 推荐：app/{Domain}/ 下只放该域相关代码，跨域调用走 Service 接口
• ❌ 反模式：app/Service/OrderService.php + app/Service/UserService.php + app/Service/OrderUserRelationService.php —— 关系类不该独立成 Service
• ⚠️ 性能注意：TP6 自动加载基于 PSR-4，app/Order/Service/ 比 app/Service/Order/ 更易命中缓存，因为命名空间更短

Service 类如何支持单元测试和替换

Service 不是工具类，它必须能被容器管理、能被 Mock、能被换实现。这意味着不能有静态方法、不能 new 具体类、不能读全局变量。所有外部依赖（DB、缓存、HTTP 客户端）必须通过构造函数注入或接口依赖。

比如 OrderService 依赖库存服务，就该依赖 StockInterface 而非 GoodsStockService。测试时用 Mock 实现，上线时 bind 到真实实现。TP6 的 app/provider.php 是绑定入口，别漏掉。

• ✅ 正确：public function __construct(private StockInterface $stock)
• ❌ 错误：new GoodsStockService()、Cache::get()、Db::table()
• ? 小技巧：在 app/common.php 里写 function app_service($name) { return app()->get($name); }，比直接 new 更利于后期切 AOP

事情说清了就结束。真正难的不是分几层，而是每次新增一个接口时，能不能忍住不把校验、查询、更新、通知全塞进一个方法里。