PHP实现DDD架构，领域驱动设计解析

本文深入解析了在PHP中践行领域驱动设计（DDD）的本质——它并非依赖框架或工具，而是一种严格的、以业务为核心的设计思维：通过聚合根严控状态变更、仓储接口彻底隔离技术细节、值对象确保不可变与内建验证，将业务规则从HTTP、数据库和框架的泥潭中剥离出来；真正的挑战不在于代码结构，而在于每一次编码决策时能否坚守“这是领域逻辑，还是技术噪声”的清醒自觉。

PHP里没有DDD框架，只有DDD思维

PHP本身不提供领域驱动设计的内置支持，DDD不是语言特性，也不是Composer包能一键装出来的模式。它是一套组织代码的约束性思路：把业务规则从框架、数据库、HTTP细节里剥离开。你写new UserController()还是new OrderService()，不决定你是否在做DDD；你让Order类自己校验“不能重复支付”、拒绝直接暴露$order->status = 'paid'，才开始靠近DDD。

聚合根必须控制内部状态变更

常见错误是把Order当DTO用，外部随意改属性、调用setter，再统一save()。这等于放弃领域逻辑的守门人角色。正确做法是只暴露意图明确的行为方法：

• Order::place() 负责检查库存、生成单号、设置初始状态
• Order::pay() 内部校验是否可支付（比如状态必须是'pending'），失败则抛DomainException
• 禁止公开setStatus()这类通用方法——状态流转必须由业务动因触发

否则，任何地方都能$order->status = 'shipped'，领域规则就形同虚设。

仓储接口定义要远离ORM实现细节

别让OrderRepository接口里出现findByUserIdAndStatus()这种带数据库字段名的方法。它应该只表达领域需求：

• ofId(OrderId $id) —— 按唯一标识加载聚合
• withStatus(OrderStatus $status) —— 返回符合业务状态的聚合集合
• add(Order $order) —— 保存新聚合

这样你才能在测试时用内存仓储（InMemoryOrderRepository）替代EloquentOrderRepository，而不影响领域层代码。一旦接口混入whereRaw()或withTrashed()，就锁死了ORM依赖。

值对象必须不可变且自含验证

像Money、Email、Address这类值对象，如果允许$money->amount = 100，就破坏了“相等性由值决定”的前提。正确写法：

final class Money
{
    public function __construct(public readonly int $amount, public readonly string $currency)
    {
        if ($amount 
<p>注意：<code>readonly</code>（PHP 8.2+）或手动私有属性+无setter，加上构造即验证，缺一不可。否则你在<code>Order</code>里用<code>new Money(-500, 'CNY')</code>也能过，领域边界就漏了。</p>

<p>真正难的不是写<code>AggregateRoot</code>接口，而是每次新增一个<code>if</code>判断、加一个<code>status</code>字段时，都得停下来问：这个逻辑属于领域规则，还是只是数据库查询条件？很多人卡在这一步，然后悄悄把校验塞进Controller或者Model的<code>save()</code>钩子里——那已经不是DDD，只是给老代码贴了张标签。</p><p>今天关于《PHP实现DDD架构，领域驱动设计解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！</p>