8

DDD の Bounded Contexts のアイデアについて読んでいますが、モデルが実際にどのように見えるかを正確に理解していないことに気づき始めています。(ドメインが何を意味するのか正確にはわからないかもしれません。)

一般的な e コマースの例を見てみましょう。顧客は商品を閲覧し、カートに追加し、注文します。注文フルフィルメント担当者が注文を発送します。

複数の境界コンテキスト (製品カタログ コンテキスト、ショッピング カート コンテキスト、注文コンテキスト、フルフィルメント コンテキスト) を持つ 1 つの大きな e コマース ドメインはありますか? 各境界コンテキストには一連のモデルが含まれていますか (製品カタログ コンテキストに製品、製品画像、製品レビューのモデルが含まれるように) ?

私はどれくらい離れていますか？

4

3 に答える 3

7

少なくともあなたは正しい道を進んでいます。典型的な間違いは、パターンだけを見ることです。

ドメインとは、あなたが扱っている問題を意味します (電子商取引、医療、会計などのサポート)。ドメイン モデルは、私たちのメンタル モデルにできるだけ近いコードで表される問題の解決策です。

一般的な e コマースの例を見てみましょう。顧客が商品を閲覧し、カートに追加し、注文します。注文フルフィルメント担当者が注文を発送します。

あなたの例では、次のようなものから始めます。

class Product { }

class Customer
{
    Cart Cart;
    void PlaceAnOrder()
    {
        order = new Order(Cart.Products);
        Orders.Add(order);
        Cart.Empty(); //if needed
    }
    Orders Orders;
    Orders UnfulfilledOrders()
    {
        Orders.Where(order => !order.IsFilled);
    }
}

class Cart
{
    void AddProduct(product)
    {
        Products.Add(product);
    }
    void Empty()
    {
        Products.Clear();
    }
}

class Order
{
    bool IsFilled;
    void Order(products)
    {
        Products = products;
        IsFilled = false;
    }
    void Fill()
    {
        IsFilled = true;
        //TODO: obviously - more stuff needed here
    }
    Money TotalPrice()
    {
        return Products.Sum(x => x.Price);
    }
}

class System
{
    void Main()
    {
        SimulateCustomerPlacingAnOrder();
        SimulateFulfillmentPeople();
    }
    void SimulateCustomerPlacingAnOrder()
    {
        customer = new Customer();
        customer.Cart.AddProduct(allProducts.First());
        allCustomers.Add(customer);
    }
    void SimulateFulfillmentPeople()
    {
        foreach (var customer in allCustomers)
        {
            foreach (var order in customer.UnfulfilledOrders())
                order.Fill();
        }
    }
}

最初は、これはやり過ぎのように思えます。手続き型コードを使用すると、少数のコレクションと少数の for ループで同じことが実現できます。しかし、ドメイン駆動設計の考え方は、本当に複雑な問題を解決することです。

オブジェクト指向プログラミングはうまく適合します - それにより、前に進むときに重要ではないものを抽象化できます。また、あなた (およびあなたのドメインの専門家 (問題を理解している人)) が何年経ってもコードを理解できるように、それに応じて名前を付けることが重要です。コードだけでなく、ユビキタスな言語で話すことも必要です。

私は電子商取引のドメインと、あなたが解決しようとしている問題の種類を知らないことに注意してください. これが、ドメイン モデリングの教育が非常に混乱し、難しい理由の 1 つです。また、私の理解によれば、CSの学位を取得するための主な要件ではない抽象的思考の優れたスキルが必要です.

境界付けられたコンテキストについては親切です。しかし、それらの間で翻訳が必要になることを覚えておく必要があります。それらは複雑さを追加し、いつものように、複雑なソリューションは複雑な問題にのみ適しています (これは ddd 自体にも当てはまります)。そのため、ドメイン エンティティの意味が重複しない限り、スパムを避ける必要があります。2番目の理由（「自然」ではない）は、分解の強い必要性です。

Psエヴァンスの本を読んでください。2回...意味がわかるまで... :)

于 2011-06-27T20:35:59.540 に答える
3

あなたの意見は正しいと思います。コンテキストは、同じ現実世界の概念のさまざまな側面を扱います。あなたのケースでは、ユーザーのためのある種のショッピング カートの抽象化として、同時に、使用されている ERP と互換性のある形式で注文を表すことができます。

注文の概念を 1 つのモデルに押し込もうとする代わりに、DDD のコンテキストでは基本的に、(異なるコンテキストで) 2 つの完全に異なるモデルを使用していくつかの概念を表現しても問題ないと言い、必要に応じてこれらのモデル間の明示的なマッピングを提供します。これにより、複数のコンテキスト内で同じモデルを使用しようとした場合に通常忍び寄るクラフトをモデルが集約するのを防ぎます。

于 2011-02-13T17:25:35.807 に答える
1

Java の例に問題がなければ、これが役に立つかもしれません: http://dddsample.sourceforge.net/

于 2010-12-23T21:22:22.837 に答える