domain-driven-design - DDD : keep a link to an entity inside an aggregate root, 仅用于报告

Question

我正在使用 DDD 重构一个项目，但我担心不会让太多实体成为他们自己的聚合根。

我有一个 Store ，其中包含 ProductOption 的列表s 和 Product 的列表s。一个 ProductOption可以多人使用Product s。这些实体似乎适合 Store聚合得很好。

然后我有一个 Order ，暂时使用 Product建立它的OrderLine s:

class Order {
    // ...
    public function addOrderLine(Product $product, $quantity) {
        $orderLine = new OrderLine($product, $quantity);
        $this->orderLines->add($orderLine);
    }
}

class OrderLine {
    // ...
    public function __construct(Product $product, $quantity) {
        $this->productName = $product->getName();
        $this->basePrice = $product->getPrice();
        $this->quantity = $quantity;
    }
}

现在看来，DDD 规则受到尊重。但是我想添加一个要求，这可能会破坏聚合规则:商店所有者有时需要检查有关包含特定产品的订单的统计信息。

这意味着基本上，我们需要在 OrderLine 中保留对 Product 的引用，但实体内的任何方法都不会使用它。在查询数据库时，我们只会将此信息用于报告目的；因此，由于此内部引用，不可能“破坏” Store 聚合内的任何内容:

class OrderLine {
    // ...
    public function __construct(Product $product, $quantity) {
        $this->productName = $product->getName();
        $this->basePrice = $product->getPrice();
        $this->quantity = $quantity;

        // store this information, but don't use it in any method
        $this->product = $product;
    }
}

这个简单的要求是否要求 Product 成为聚合根？这也将级联到 ProductOption 成为聚合根，因为 Product 有对它的引用，从而导致两个聚合在 Store 之外没有意义，并且不需要任何存储库；对我来说看起来很奇怪。

欢迎任何评论!

Answer 1

即使它用于“仅报告”，仍然有业务/领域的含义。我觉得你的设计很好。虽然我不会通过存储 OrderLine -> Product 来处理新的需求引用。我会做一些类似于您已经在产品名称和价格方面所做的事情。您只需要在订单行中存储某种产品标识符( SKU ？)。此标识符/SKU 稍后可以在查询中使用。 SKU 可以是 Store 和 Product 自然键的组合:

class Sku {
    private String _storeNumber;
    private String _someProductIdUniqueWithinStore;
}

class OrderLine {
    private Money _price;
    private int _quantity;
    private String _productName;
    private Sku _productSku;
}

这样您就不会违反任何聚合规则，并且可以安全地删除产品和商店，而不会影响现有或存档的订单。而且您仍然可以拥有“来自 StoreY 的 ProductX 订单”。
更新:关于您对外键的关注。在我看来，外键只是一种在数据库级别强制执行长期域关系的机制。由于您没有域关系，因此您也不需要强制机制。