PHP 怎么划分模块边界

wen PHP项目 2026-08-11 4

本文目录导读：

PHP 怎么划分模块边界

物理边界：命名空间与目录结构（基础）
依赖边界：Composer 包管理（最强制）
逻辑边界：接口（Interface）与依赖倒置
领域边界：DDD（领域驱动设计）战术模式
单一职责边界：文件与类设计
实施建议：如何落地？
边界的本质

在 PHP 中划分模块边界是一个架构设计问题，核心目标是降低耦合、提高内聚，PHP 不像 Java 有强制性的 package 或 module 机制，但可以通过命名空间、目录结构、Composer 依赖、接口契约以及分层架构来划分边界。

以下是 PHP 项目划分模块边界的完整策略，从基础到进阶：

物理边界：命名空间与目录结构（基础）

这是最直接的边界划分,使用 PSR-4 自动加载规范，让命名空间与目录一一对应。

原则：按业务域（Domain） 划分，而不是按技术类型（Controller, Model）划分。
反模式：app/Controllers/、app/Models/（按技术划分）。
推荐模式：app/Modules/User/、app/Modules/Order/。

app/
├── Modules/
│   ├── User/
│   │   ├── Controllers/
│   │   ├── Services/
│   │   ├── Repositories/
│   │   └── Models/
│   ├── Payment/
│   │   ├── Controllers/
│   │   ├── Services/
│   │   └── Gateways/
│   └── Order/
│       └── ...
└── Shared/  // 核心共享层（基础设施）
    └── Traits/

依赖边界：Composer 包管理（最强制）

将模块拆分为独立的 Composer 包，是 PHP 中最严格的边界划分方式。

实施：在 composer.json 中使用 "autoload" 配置映射各自的命名空间。
约束：Order 模块需要依赖 Payment 模块，必须显式在 Order 模块的 composer.json 中声明 "require"，如果未声明，而代码直接使用了 Payment 的类，IDE 和静态分析工具（如 PHPStan）会立即报警。
内部包：即使不发布到 Packagist，也可以在根项目的 repositories 中配置 path 类型，将它们作为本地 VCS 包管理。

逻辑边界：接口（Interface）与依赖倒置

这是解耦的核心,模块之间不应依赖具体类，而应依赖接口。

策略：定义接口在消费方（使用方），实现类在提供方。
场景：Order 模块需要计算运费，但运费逻辑在 Shipping 模块。
```
// 边界定义（在 Order 模块中）
interface ShippingCalculatorInterface {
    public function calculateCost(Order $order): Money;
}
```
Order 模块的 Service 只注入这个 Interface，具体的 FedExCalculator 在 Shipping 模块中实现，并通过容器（如 Laravel的 ServiceProvider）绑定注入。结果：Order 模块不知道 Shipping 模块的存在。

领域边界：DDD（领域驱动设计）战术模式

对于复杂业务,按 DDD 的 Bounded Context（限界上下文）划分。

划分：每个模块（如：销售、库存、财务）都是独立的限界上下文。
核心规则：
- 模块之间禁止共享数据库表（物理隔离）。
- 模块之间禁止直接调用对方的 Repository。
- 只能通过 Domain Events（领域事件） 或 Application Service 进行通信。
- 数据同步通过事件（如 OrderPlaced 事件触发 Inventory 模块扣减库存）。

单一职责边界：文件与类设计

在同一个模块内部,也要划分清晰的职责边界，避免上帝类。

Action 模式：一个类只做一件事。User 模块下拆分为 RegisterUser、UpdateUserProfile、ChangePassword 三个 Action 类，而不是一个 UserService 处理所有。
DTO（数据传输对象）：跨模块传参时，不要直接传递 Eloquent Model 或 Entity，应传递轻量级 DTO，防止模块 A 的实体修改直接污染模块 B 的逻辑。

实施建议：如何落地？

如果你有一个现有的混乱项目,建议按以下步骤逐步推进：

第一步：梳理显式依赖 检查 use 语句，找出耦合点，确定哪些模块可以合并，哪些必须拆分。
第二步：定义接口层 禁止模块 A 直接 new 模块 B 的类，引入 Interface 和依赖注入容器（PSR-11）。
第三步：建立“防腐层”（Anti-Corruption Layer） 如果无法完全隔离数据，在模块 A 和 B 之间建立一个转换层，负责翻译双方的模型和数据结构。
第四步：利用工具强制约束
- Deptrac：这是一个 PHP 静态分析工具，专门用来定义和检查模块依赖规则，你可以在 deptrac.yaml 中声明“Order 模块不允许依赖 Inventory 模块”，并集成到 CI，若违反则构建失败。
- PHPStan / Psalm：配合 @api 注解或 --level=8 严格检查未定义的依赖。

边界的本质

PHP 的模块边界不仅是代码层面的物理隔离，更是团队之间的口头协议。

顶层（目录）：决定代码放在哪里。
中间层（Composer + Interface）：决定谁允许知道谁。
底层（事件/异步消息）：实现最终一致性和物理解耦。

最简单的判断标准：如果修改 User 模块的内部代码，会导致 Order 模块的测试失败，那么这两个模块的边界就不清晰，需要重构。