DDD聚合根行为争议：发票聚合根能否实例化投诉聚合根？

首先得说，你和同事的分歧本质上是DDD中聚合根边界与职责的划分问题——你的思路能实现功能，但确实不符合DDD的核心设计原则，同事的顾虑是有道理的。

先拆解下为什么直接在Invoice聚合根里实例化Complaint是不合适的：

• 破坏聚合根的封装性：isOpened是Complaint聚合根的内部状态细节，Invoice根本不应该直接依赖这个字段。哪天Complaint团队把判断"未办结"的逻辑改成了isPending()或者更复杂的规则，你这边的Invoice代码就得跟着改，完全违反了开闭原则。
• 职责错位：Invoice聚合根的核心职责是管理发票自身的生命周期（比如创建、修改状态、删除），而"检查关联投诉状态"是跨两个聚合根的业务规则，不属于单个聚合根的职责范围。把跨聚合的逻辑塞进单个聚合根，会让它越来越臃肿，变成难以维护的大泥球。
• 潜在的一致性与性能问题：加载整个Complaint聚合根可能带来不必要的性能开销（如果Complaint包含大量关联数据的话）。更糟的是，如果你查询Complaint和执行Invoice删除之间有时间差，另一个线程可能修改了Complaint的状态，导致规则校验失效，出现数据不一致的情况。

那正确的做法应该是什么？这里有两种常用的DDD方案：

方案1：用领域服务处理跨聚合规则 #

创建一个领域服务（比如InvoiceDomainService），把跨聚合的校验逻辑放在这里：

public class InvoiceDomainService {
    private final InvoiceRepository invoiceRepo;
    private final ComplaintRepository complaintRepo;

    // 构造函数注入仓库
    public InvoiceDomainService(InvoiceRepository invoiceRepo, ComplaintRepository complaintRepo) {
        this.invoiceRepo = invoiceRepo;
        this.complaintRepo = complaintRepo;
    }

    public void deleteInvoice(Long invoiceId) {
        // 1. 校验：查询该发票是否有未办结的投诉（不需要加载整个聚合根，只查状态即可）
        boolean hasOpenComplaint = complaintRepo.existsOpenComplaintByInvoiceId(invoiceId);
        if (hasOpenComplaint) {
            throw new DomainException("无法删除：该发票存在未办结的投诉");
        }

        // 2. 调用Invoice聚合根的删除方法（聚合根内部处理自身的状态变更）
        Invoice invoice = invoiceRepo.findById(invoiceId);
        invoice.markAsDeleted(); // 或者直接删除，根据你的业务逻辑
        invoiceRepo.save(invoice);
    }
}

这里的关键是：

• 领域服务专门处理跨聚合的业务规则，它是协调多个聚合根的核心角色
• 尽量避免加载整个Complaint聚合根，而是通过仓库提供的专用查询方法（比如existsOpenComplaintByInvoiceId）直接获取校验结果，既高效又避免依赖Complaint的内部细节

方案2：维护发票侧的状态标记（适合高频校验场景） #

如果这个删除校验的场景非常频繁，或者你不想每次删除都查Complaint表，可以在Invoice聚合根里加一个hasOpenComplaint的字段，然后通过领域事件来同步状态：

1. 当创建未办结的Complaint时，发布ComplaintOpenedEvent事件
2. 当Complaint办结时，发布ComplaintClosedEvent事件
3. 监听这两个事件，更新对应Invoice的hasOpenComplaint字段

这样删除Invoice时，只需要检查自己的hasOpenComplaint字段即可，完全不需要依赖Complaint聚合根：

public class Invoice {
    private boolean hasOpenComplaint;

    public void delete() {
        if (hasOpenComplaint) {
            throw new DomainException("无法删除：该发票存在未办结的投诉");
        }
        // 处理自身的删除逻辑
    }
}

这个方案的好处是性能更高，但需要额外处理事件同步的一致性问题（比如用事务+事件总线保证状态同步），适合对性能要求高的场景。

总结一下：同事的反对是基于DDD中聚合根"高内聚、低耦合"的核心原则，你的思路虽然能快速实现功能，但长期来看会导致代码耦合严重、维护成本上升。用领域服务或者状态同步的方式，才是符合DDD设计的正确做法。

内容的提问来源于stack exchange，提问作者julien M