PHP数据库分层架构核心是分离数据访问与业务逻辑，分为DAO/Repository（专注查询）、领域模型（定义实体/值对象/DTO）、Service（编排业务用例）、适配层（处理请求响应），各层职责清晰、单向依赖、易于测试和维护。
PHP 数据库分层架构的核心是把数据访问逻辑从业务逻辑中剥离，让各层职责清晰、可测试、易维护。不是堆砌设计模式，而是围绕“变化点”做隔离——比如数据库换 MySQL 为 PostgreSQL、查询逻辑调整、缓存策略变更，这些改动应尽量只影响一层。
数据访问层（DAO / Repository）专注“怎么查”
这一层只负责与数据库交互，不处理业务规则，也不组装领域对象。用 PDO 或 Doctrine DBAL 封装连接、预处理、事务，避免 SQL 拼接。每个实体对应一个 DAO 类，方法名体现意图，如 findByStatusAndDateRange() 而非 query()。
- SQL 写在类内部或单独的 SQL 文件里，不散落在 Service 中
- 返回数组或值对象（DTO），不返回 Eloquent 模型或 ActiveRecord 实例
- 支持简单注入：DAO 构造时接收 PDO 实例，便于单元测试 mock
领域模型层（Entity / VO / DTO）定义“是什么”
这里放纯 PHP 类，无数据库耦合。Entity 表达核心业务概念（如 Order、User），含必要验证和行为；VO（Value Object）表达不可变结构（如 Money、Address）；DTO 用于层间数据传递（如 UserDTO 用于 API 输出）。
- Entity 不继承任何框架基类，不带 save() / delete() 方法
- DTO 可用 PHP 8.0+ 的只读属性或构造器赋值，避免意外修改
- 避免在 Entity 中调用 DAO 或 Service，保持单向依赖
业务服务层（Service）编排“做什么”
这是协调者：调用多个 DAO 获取数据，组合 Entity，执行校验、计算、事件通知等。它不关心 SQL 怎么写，也不直接操作数据库连接。一个 Service 方法通常对应一个完整业务用例（如 “创建订单并扣减库存”）。
立即学习“PHP免费学习笔记（深入）”；
- 方法粒度适中，避免过长逻辑；复杂流程可拆为私有方法或引入 Domain Service
- 事务控制放在 Service 层（PDO::beginTransaction 等），DAO 只提供原子操作
- 异常按语义抛出（如 InsufficientStockException），不暴露 PDOException
适配层（Controller / API Gateway）只管“怎么来、怎么回”
接收 HTTP 请求、解析参数、调用 Service、格式化响应。它不包含任何数据库相关代码，也不做业务判断。输入转为 DTO 或 Value Object，输出由 Service 返回的领域对象再映射为 JSON/HTML。
- 参数验证用独立 Validator 类或 PHP 8.0+ 属性（#[Validate]）配合中间件
- 响应组装与序列化（如 json_encode）在此层完成，不侵入 Service
- 若需兼容多端（Web/API/CLI），可抽象统一接口，Controller 只做协议适配
分层不是越多越好，小项目用 DAO + Service + Controller 三层已足够。关键是在 DAO 和 Service 边界处画清“谁该知道数据库，谁不该知道”，后续加缓存、换 ORM、接入消息队列，才不会牵一发而动全身。
