Question

我正在阅读关于DDD中有界上下文的想法，我开始意识到我并没有清楚地理解 Model 在实践中的样子。（我甚至可能都不确切知道 Domain 的含义。）

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

是否有一个具有多个有界上下文的大型电子商务域（产品目录上下文，购物车上下文，订单上下文，实现上下文）？每个有界上下文是否包含一组模型（因此产品目录上下文包含产品模型，产品图像，产品评论）？

我离我有多远？

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本身也是如此）。所以 - 只要您的域实体的含义不重叠，您就应该避免发送垃圾邮件。第二个原因（较少“自然”）将强烈需要分解。

P.S。阅读Evans book。两次......直到它有意义......：）

Answer 2

我认为您的观点是准确的。上下文涉及同一现实世界概念的不同方面。在您的情况下，您可能会将订单表示为用户的某种购物车抽象，同时以某种形式与使用的ERP兼容。

DDD的上下文基本上表示使用两个完全不同的模型（在不同的上下文中）表示一些概念，而不是试图将订单概念强加于单个模型中，在需要时提供这些模型之间的显式映射。如果试图在多种情境中使用相同的模型，这可以防止模型聚合通常会悄悄进入的模型。

Answer 3

如果您对java中的示例没问题，这可能很有用：http://dddsample.sourceforge.net/

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

3 个答案: