PHP聚合根怎么理解

wen PHP项目 2026-08-11 2

PHP聚合根深度拆解：从领域模型到代码实践的完整指南

PHP聚合根怎么理解

目录导读

聚合根是什么？为什么它总被“误解”？
聚合根与实体、值对象的边界划分
PHP中实现聚合根的实战要点（含代码示例）
聚合根与仓储、应用服务的协作原则
常见设计陷阱与性能权衡（附高频问答）
聚合根不是银弹，但它是DDD的锚点

聚合根是什么？为什么它总被“误解”？

在PHP开发社区，提到“聚合根”（Aggregate Root），很多人第一反应是“不就是把几个对象包在一个类里吗？”——这是最大的误解，聚合根是领域驱动设计（DDD）中的核心概念，它不是简单的“大对象”，而是一个一致性边界的守护者。

根据Eric Evans在《领域驱动设计》中的定义，聚合是一组相关对象的集合，聚合根是这个集合的唯一外部访问入口，外部对象只能引用聚合根，不能直接持有聚合内部的其他对象引用，这保证了聚合内部的不变量（Invariant）在每次状态变更后依然成立。

打个比方：一个订单（Order）聚合包含订单项（OrderItem）、配送地址（ShippingAddress）等，当你修改订单时，必须通过订单聚合根的方法（如addItem()、changeShippingAddress()），而不是直接拿到OrderItem去改数量，因为订单总额、库存扣减等业务规则需要整体校验。

为什么PHP开发者容易误解？ 因为PHP的弱类型和灵活数组，让大家习惯了“传数组、改数组”的开发方式，导致边界感模糊，而在Java等强类型语言中，聚合根更容易通过接口约束体现，PHP中需要开发者自律：用final类、私有属性、构造器注入等手段强制边界。

聚合根与实体、值对象的边界划分

在DDD中,聚合内的对象分为两类：

实体（Entity）：有唯一标识（ID），且生命周期持续变化，例如订单项有id，其数量、价格会变。
值对象（Value Object）：没有ID，由属性值本身定义，不可变，例如金额（Money）、地址（Address）,两个属性相同的值对象是相等的。

聚合根本身就是实体,但它还具有以下额外职责：

维护全局一致性：聚合内所有对象的业务规则必须由聚合根统一调度。
定义事务边界：一次事务只能修改一个聚合实例，这意味你不能在一个事务里同时修改订单和用户（除非它们属于同一个聚合）。
控制并发：通过版本号或乐观锁,确保多个请求不会同时修改聚合内部状态。

实战中的边界判定标准：

问“如果删除这个对象，其他对象还有意义吗？” 如果无意义,它可能是聚合的一部分。
问“外部是否直接操作这个对象的内部字段？” 如果是,你需要加强封装。

用户（User）和订单（Order）通常是两个聚合，订单引用用户ID，但用户不是订单的一部分，你不能通过订单直接触发用户改名——这需要通过领域事件或应用服务协调。

PHP中实现聚合根的实战要点（含代码示例）

我们用一个经典的Post（文章）和Comment（评论）例子，规则：一篇文章可以有多个评论，但新增评论时必须校验文章状态为published,且评论字数不能超过500。

final class Post {
    private string $id;
    private string $title;
    private string $status; // draft, published
    /** @var Comment[] */
    private array $comments = [];
    public function __construct(string $id, string $title) {
        $this->id = $id;
        $this->title = $title;
        $this->status = 'draft';
    }
    public function publish(): void {
        if ($this->status === 'published') {
            throw new \LogicException('文章已发布');
        }
        $this->status = 'published';
    }
    public function addComment(string $commentId, string $content): void {
        if ($this->status !== 'published') {
            throw new \DomainException('只有已发布的文章才能评论');
        }
        if (mb_strlen($content) > 500) {
            throw new \DomainException('评论不能超过500字');
        }
        // 直接由聚合根创建Comment，不暴露内部数组
        $this->comments[] = new Comment($commentId, $content);
    }
    public function getCommentIds(): array {
        return array_map(fn(Comment $c) => $c->getId(), $this->comments);
    }
}
final class Comment {
    private string $id;
    private string $content;
    public function __construct(string $id, string $content) {
        $this->id = $id;
        $this->content = $content;
    }
    public function getId(): string { return $this->id; }
}

关键点解析：

Post的addComment()封装了所有校验逻辑（状态、字数）。
comments属性是私有数组，外部无法直接$post->comments[] = ...。
Comment没有setter，不可变,符合值对象特征。
聚合根提供getCommentIds()而不是返回对象数组,防止外部修改内部状态。

注意：如果需要保存聚合，数据映射器（Mapper）应通过聚合根暴露的方法获取状态,而不是反射直接读取私有属性。

聚合根与仓储、应用服务的协作原则

在PHP框架（如Laravel、Symfony）中，常见的错误是把聚合根当“ActiveRecord”用，让聚合根自带save()方法，这违背了DDD的初衷,正确的分层是：

应用服务（Application Service）：负责事务边界、权限控制、协调多个聚合，例如CreateCommentService会同时调用Post聚合和User聚合（如果需要积分）。
仓储（Repository）：负责从存储介质（Mysql、Redis）重建聚合，以及持久化聚合，仓储接口在领域层,实现在基础设施层。

一个标准流程（伪代码）：

class CommentService {
    public function __construct(
        private PostRepository $postRepo,
        private UnitOfWork $uow
    ) {}
    public function addComment(string $postId, string $userId, string $content): void {
        $post = $this->postRepo->findById($postId);
        $post->addComment(Uuid::generate(), $content); // 聚合根校验逻辑
        $this->uow->commit(); // 只保存这一个聚合
    }
}

原则：

一个Use Case（用例）只修改一个聚合根，如果需要多聚合联动,请使用领域事件。
仓储的save方法应保存整个聚合的内部状态变化,而不是只保存单个实体。
不要将EntityManager或DBAL Connection注入聚合根,聚合根应该是纯内存对象。

常见设计陷阱与性能权衡（附高频问答）

陷阱1：聚合根过大，把整个用户、订单、商品全塞进一个聚合，导致锁竞争和性能瓶颈，解决：按业务“改变频率”和“一致性要求”拆小聚合。

陷阱2：过度使用级联操作，聚合根内部对象引用关系太深，导致每次加载都要JOIN许多表，解决：使用“分步加载”或“只加载ID”,但需警惕一致性减弱。

陷阱3：忽略乐观锁，聚合根通常带version字段，更新时WHERE version = ?，PHP开发者常忘了这一点,导致并发下数据覆盖。

问答环节：

Q1：聚合根可以引用其他聚合根吗？ A：可以，但只能引用其ID，不能直接持有另一个聚合根的对象引用，否则破坏了边界，例如Post聚合中可以存$authorId，但不应存User对象。

Q2：聚合根内部的对象需要分别建表吗？ A：通常聚合内对象一起存储，可以使用JSON列（MySQL 5.7+）或者设计成一张宽表，这取决于查询模式，如果评论频繁单独展示，拆表可能更优,但此时需重新评估评论是否应独立为聚合。

Q3：PHP的数组那么灵活，直接用数组当聚合不行吗？ A：不行，数组无法封装业务规则——任何代码都能往数组里塞数据，无法保证不变量，聚合根的优势在于“行为”带动“数据”,而不是数据的裸暴露。

Q4：聚合根和工厂模式（Factory）有什么关系？ A：工厂（如PostFactory）负责创建聚合根，并保证创建时满足不变量，聚合根的构造函数应尽可能完整,避免创建后还需要一堆setter。

Q5：聚合根内部是否可以有跨聚合的领域事件？ A：可以，聚合根内部状态改变时，可以记录待发布事件（如PostPublishedEvent），应用服务在事务提交后，通过消息队列发布这些事件,这是异步解耦的关键。

聚合根不是银弹，但它是DDD的锚点

在PHP项目中实施聚合根，意味着你必须放弃“ActiveRecord式”的爽快，接受更严谨的编码规范，但这换来的是业务逻辑的可维护性和系统演进的稳定性，如果项目是CRUD管理系统（比如后台表格），聚合根可能过度设计；如果是复杂的订单、库存、支付领域，聚合根能显著减少“改一处漏三处”的Bug。

最后建议：从最小的聚合（一个实体+几个值对象）开始实践，等理解了“一致性边界”的真谛，再扩展，聚合根的名字里有“聚合”，但核心在于根——它是一棵树的入口,也是你代码中业务规则的守护者。

希望这篇文章帮你从“听说过聚合根”进阶到“会用聚合根”，如果你正在用Laravel或Symfony，不妨尝试把某个核心业务模块重构为聚合根模式,你会感受到DDD的魅力。