PHP项目分层设计是为了实现解耦、可测与易维护，通过职责划分明确Controller、Service、Domain、Infrastructure各层分工，并支持贫血或充血模型选择及分层测试。
为什么 PHP 项目要分层设计？
分层不是为了炫技，而是为了解耦、可测、易维护。PHP 项目一旦业务变多、团队变大，把所有逻辑塞在控制器或一个文件里，很快就会变成“意大利面条代码”。分层本质是按职责划界：谁负责接收请求，谁处理业务规则，谁操作数据库，谁组装响应——各司其职，改一处不影响其他。
MVC 是唯一选择吗？常见分层结构有哪些？
不是。MVC（Model-View-Controller）在简单 Web 应用中够用，但中大型 PHP 项目常采用更清晰的分层方式，比如：
- Controller 层：只做请求解析、参数校验、调用 Service、返回响应。不写业务逻辑，也不直接查库。
- Service 层（或 Application 层）：承载核心业务流程，协调多个 Domain 或 Repository，处理事务、状态流转、领域规则。例如“下单”要扣库存、生成订单、发消息，都在这一层编排。
- Domain 层（或 Model 层）：包含实体（Entity）、值对象（Value Object）、领域服务（Domain Service）、仓储接口（Repository Interface）。强调业务语义，不依赖框架或数据库。
- Infrastructure 层：实现 Domain 中定义的 Repository 接口，对接 MySQL、Redis、第三方 API 等。DAO、Eloquent Model、HTTP Client 封装都放这里。
- DTO / VO / Request / Response 类：各层之间传递数据用专用对象，避免直接暴露 Entity 或数组嵌套，提升可读性和安全性。
怎么体现“领域驱动”和“贫血模型”的区别？
面试常考这点。关键看业务逻辑放在哪：
- 贫血模型：Entity 只是属性容器（getter/setter），所有逻辑堆在 Service 里。好处是简单，适合 CRUD 主导的系统；缺点是业务规则散落、难以复用、不易表达领域语义。
- 充血模型（DDD 风格）：Entity 自己封装行为。例如 Order::confirm() 内部检查状态、更新时间、触发事件，而不是让 OrderService::confirmOrder($order) 去判断一堆 if。这要求 Entity 有明确不变量和生命周期，对团队抽象能力要求更高。
实际项目中不必强求充血，但需意识到：当某个 Entity 的行为反复在多个 Service 中重复出现（如 “计算优惠后价格”、“校验是否可退款”），就该考虑把它收归到 Domain 层。
立即学习“PHP免费学习笔记（深入）”；
分层后如何保证测试友好性？
分层的价值，一大半体现在可测试性上：
- Controller 单元测试：用 PHPUnit + HttpKernel 模拟请求，验证输入校验、状态码、响应结构，不走真实 DB。
- Service 测试：注入 Mock 的 Repository 和 Domain Service，专注验证业务流程是否按预期调用、组合、抛异常。
- Domain 测试：完全隔离外部依赖，纯对象行为测试。例如测试 Coupon::canUseBy($user) 是否正确结合了过期时间、使用次数、用户等级。
- Infrastructure 测试：可选做集成测试，用 SQLite 内存库或 Testcontainers 启 MySQL，验证 SQL 是否生成正确、事务是否生效。
记住：越靠近 Domain 的代码，越该被高频、快速、独立地测试；越靠近 Infrastructure 的代码，越要少写逻辑、多交由框架或数据库保障正确性。
