DDD -有界上下文和多模型？

Question

我正在阅读DDD中有界上下文的概念，并且我开始意识到我对模型在实践中的具体情况没有一个明确的理解。(我甚至可能也不知道域的确切含义。)

让我们看看流行的电子商务例子:客户浏览产品，添加到他们的购物车，下订单。履行命令的人发出命令。

是否有一个具有多个有限制上下文的大型电子商务域(产品目录上下文、购物车上下文、订单上下文、实现上下文)？每个有界上下文是否包含一组模型(因此products上下文包含产品、产品映像和产品评论的模型)？

我还有多远？

Answer 1

至少你已经走上正轨了。典型的错误是只看到模式。

域意味着您正在处理的问题(支持电子商务、医疗保健、会计等)。域模型是在代码中表示的问题的解决方案，它尽可能接近我们的心智模型。

让我们看看流行的电子商务例子:客户浏览产品，添加到他们的购物车，下订单。履行命令的人发出命令。

在您的示例中，我将从以下内容开始：

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循环来实现相同的目标。但是，领域驱动设计的思想是解决真正复杂的问题。

面向对象的编程非常适合--使用它，您可以抽象出在前进过程中不重要的东西。此外，重要的是要相应地命名事物，这样您(和您的领域专家(了解问题的人))即使在几年后也能够理解代码。不仅要用代码，还要用一种无处不在的语言说话。

请注意，我不知道电子商务领域和你可能试图解决什么样的问题，因此-这很可能我只是写了完全胡说八道根据你的心理模型。这就是为什么教学领域建模如此混乱和困难的原因之一。此外，它需要很强的抽象思维能力，据我理解，这并不是获得CS学位的主要要求。

对于有界的上下文，你是一种权利。但你应该记住，它们增加了它们之间的翻译需求。它们增加了复杂性，通常复杂的解决方案只适用于复杂的问题( ddd本身也是如此)。所以-你应该避免垃圾邮件，只要你的领域实体的意义不重叠。第二个原因(较少的“自然”)是强烈的分解需求。

附注：读埃文斯书。两次..。直到有意义..。:)

Answer 2

我认为你的观点是正确的。语境处理同一个现实世界概念的不同方面。在您的示例中，您可能有一个订单，它表示为用户提供某种类型的购物车抽象，同时以某种形式与使用的ERP兼容。

DDD的上下文不是试图将顺序的概念压缩到单个模型中，而是基本上可以使用两个完全不同的模型(在不同的上下文中)来表示某个概念，并在需要时提供这些模型之间的显式映射。这将防止模型聚集通常在多种上下文中使用相同模型时会出现的cruft。

Answer 3

如果您可以使用java中的示例，这可能是有用的：http://dddsample.sourceforge.net/