2

DDD を使用してプロジェクトをリファクタリングしていますが、あまりにも多くのエンティティを独自の集約ルートにしないことが心配です。

StoreのリストとProductOptionのリストを持つがありProductます。AProductOptionは複数の s で使用できますProduct。Storeこれらのエンティティは、集計に非常によく適合しているようです。

次にOrder、一時的に a を使用してそのsProductを構築する があります。OrderLine

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;
    }
}

この単純な要件は、製品が集約ルートになることを示していますか? これはまた、ProductOption が集約ルートになるようにカスケードし、Product がそれへの参照を持っているため、ストアの外では意味を持たず、リポジトリを必要としない 2 つの集約になります。私には奇妙に見えます。

どんなコメントでも大歓迎です！

4

2 に答える 2

3

「レポート専用」ですが、ビジネス/ドメインの意味はまだあります。あなたのデザインは良いと思います。参照を保存することで新しい要件を処理することはしませんが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 の注文」を引き続き行うことができます。

更新: 外部キーに関する懸念について。私の意見では、外部キーは、データベース レベルで長寿命のドメイン関係を強制するメカニズムにすぎません。ドメイン関係がないため、強制メカニズムも必要ありません。

于 2011-09-16T03:43:03.977 に答える
0

この場合、集計ルートとは関係のないレポート用の情報が必要です。

そのため、最も適した場所はサービスです (ビジネスに関連する場合はドメイン サービスである可能性があり、必要なデータをクエリし、プレゼンテーションまたはコンシューマー向けにカスタマイズ可能な DTO として返すクエリ サービスなどのアプリケーション サービスに適している場合もあります)。

クエリ モデルでドメインを破壊する代わりに、DTO を返す読み取り専用リポジトリ (または望ましい Finder) を使用して必要なデータをクエリする統計サービスを作成することをお勧めします。

これをチェック

于 2011-09-15T11:58:11.807 に答える