1

thisやthisのような多くの議論は、RICH DOMAIN MODELに関連しています。

amenic については、1 と 3 のように 2 つの強力な理由があります。

ここで、製品が在庫に存在することを検証し、存在しない場合は例外をスローする必要があることを確認する必要があるとしましょう。

ISomeRepository質問があります: オブジェクトがサービスのように依存する必要がない場合は、次のようにできますか?

public void Order.AddOrderLine(IEnumerable<Product> products, Product product)
{
    if(!prosucts.Contains(product))
         throw new AddProductException

    OrderLines.Add(new OrderLine(product));
}

次のように呼び出します。

Order.AddOrderLine(ISomeRepository.GetAll(), product);
4

2 に答える 2

1

ここのドメインには概念が欠けているようです。StoreInventory製品が在庫から注文に移動するような、ある種のエンティティを導入することを考えています(これは、多くのコマース ドメインで「ピッキング」と呼ばれます)。

interface StoreInventory
{
    IEnumerable<Product> AvailableProducts { get; }
    Product PickProduct(guid productId); // This doesn't have to be an Id, it could be some other key or a specification.
}

void Order.AddOrderLine(StoreInventory inventory, Product product)
{
    if (!inventory.AvailableProducts.Contains(product.Id))
        throw new AddProductException();

    var item = inventory.Pick(product);
    OrderLines.Add(new OrderLine(item);
}

これは、私にとってより現実に近いように思えます。しかし、DDD ではいつものように、物事がどのように流れるべきかを教えてくれるのはドメインの専門家だけです。

これは、将来的にはさらに拡張可能と思われます。たとえば、このモデルを使用すると、それぞれに独自の在庫を持つ複数の店舗を簡単に導入できます。

于 2013-12-17T19:39:03.043 に答える
0

DDD について読むと、Repository が DDD の中核概念であることがわかります。DDD では、リポジトリはドメインの一部であり、ドメインが永続的に機能するために必要な動作の種類を示します。あなたの場合、リポジトリをメソッドに渡すだけで、メソッドに必要なデータをプルさせることができます。

public void Order.AddOrderLine(ISomeRepository repo, Product product)
{
    if(!repo.ProductExists(product))
         throw new AddProductException

    OrderLines.Add(new OrderLine(product));
}

// call it like
Order.AddOrderLine(someRepository, product);

あなたの混乱の問題は、リポジトリ、またはより正確には抽象化であり、多くの場合、永続性自体に結び付けられていることだと思います。これは実際にはパターン全体の誤解によって引き起こされた誤解です。適切なリポジトリは 2 つの部分で構成されます。通常はインターフェイスで表される抽象化であり、ドメインが永続性から必要とする操作の種類を定義します。そして、使用されている永続化テクノロジを介してこれらの操作を実装する具体的な実装。

于 2013-12-17T19:30:16.990 に答える