PHP怎么实现领域驱动设计_PHP DDD架构模式应用【介绍】

本篇文章给大家分享《PHP怎么实现领域驱动设计_PHP DDD架构模式应用【介绍】》，覆盖了文章的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

PHP无DDD框架，仅有DDD思维：需将业务规则与技术细节分离，通过聚合根控制状态变更、仓储接口抽象化、值对象不可变等实践落实领域驱动设计。

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 
注意：readonly（PHP 8.2+）或手动私有属性+无setter，加上构造即验证，缺一不可。否则你在Order里用new Money(-500, 'CNY')也能过，领域边界就漏了。

真正难的不是写AggregateRoot接口，而是每次新增一个if判断、加一个status字段时，都得停下来问：这个逻辑属于领域规则，还是只是数据库查询条件？很多人卡在这一步，然后悄悄把校验塞进Controller或者Model的save()钩子里——那已经不是DDD，只是给老代码贴了张标签。
文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP怎么实现领域驱动设计_PHP DDD架构模式应用【介绍】》文章吧，也可关注golang学习网公众号了解相关技术文章。