DDD - ограниченный контекст и несколько моделей? - PullRequest
7 голосов
/ 23 декабря 2010

Я читаю об идее ограниченного контекста в DDD и начинаю понимать, что у меня нет четкого понимания того, как именно Модель выглядит на практике. (Возможно, я даже не знаю точно, что означает домен .)

Давайте рассмотрим популярный пример электронной коммерции: покупатель просматривает товары, добавляет их в корзину, размещает заказ. Люди, выполняющие заказы, отправляют заказы.

Существует ли один большой домен электронной коммерции с несколькими ограниченными контекстами (контекст каталога товаров, контекст корзины покупок, контекст заказа, контекст выполнения)? Содержит ли каждый ограниченный контекст набор моделей (чтобы контекст каталога продуктов содержал модели для продуктов, изображения продуктов, обзоры продуктов)?

Как далеко я?

Ответы [ 3 ]

7 голосов
/ 28 июня 2011

По крайней мере, вы на правильном пути. Классическая ошибка - видеть только шаблоны.

Домен означает проблемы, с которыми вы сталкиваетесь (поддержка электронной коммерции, здравоохранения, бухгалтерского учета и т. Д.). Модель предметной области - это решение тех проблем, представленных в коде, который максимально приближен к нашей ментальной модели.

Давайте посмотрим на популярный пример электронной коммерции: покупатель просматривает товары, добавляет в корзину, размещает заказ. Люди, выполняющие заказы, отправляют заказы.

В вашем примере я бы начал с чего-то вроде этого:

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

В начале - это кажется огромным перебором. С процедурным кодом - то же самое может быть достигнуто с помощью нескольких коллекций и нескольких циклов. Но идея доменного дизайна заключается в решении действительно сложных проблем.

Объектно-ориентированное программирование прекрасно вписывается - с его помощью вы можете абстрагироваться от вещей, которые не имеют значения, когда вы продвигаетесь вперед. Кроме того - важно называть вещи соответствующим образом, чтобы Вы (и эксперты Вашего домена (люди, которые понимают проблему)) могли понимать код даже спустя годы. И не только код, но и говорить на одном вездесущем языке.

Обратите внимание, что я не знаю домен электронной коммерции и какие проблемы Вы можете пытаться решить, поэтому весьма вероятно, что я просто написал полную чепуху в соответствии с Вашей ментальной моделью. Это одна из причин, почему преподавание предметной области настолько запутанно и сложно. Кроме того - это требует большого навыка абстрактного мышления, которое, по моему пониманию, не является основным требованием для получения степени CS.


Вы любезно относитесь к ограниченным контекстам. Но вы должны помнить, что они добавляют необходимость перевода между ними. Они добавляют сложность и, как обычно, комплексное решение подходит только для сложных задач (это верно и для самого DDD). Итак, вы должны избегать спама, если значения ваших доменных сущностей не пересекаются. Вторая причина (менее «естественная») - сильная потребность в разложении.

P.s. Прочитайте книгу Эванса . Дважды ... Пока это не имеет смысла ...:)

3 голосов
/ 13 февраля 2011

Я думаю, что ваше мнение верно. Контексты имеют дело с различными аспектами одной и той же концепции реального мира. В вашем случае у вас может быть заказ, представленный как некая абстракция корзины покупателя для пользователя и в то же время в некоторой форме, совместимой с используемым ERP.

Вместо того, чтобы пытаться включить концепцию порядка в единую модель, контексты DDD в основном говорят, что можно представлять некоторую концепцию, используя две совершенно разные модели (в разных контекстах), обеспечивая явное отображение между этими моделями по мере необходимости. Это предотвращает агрегацию моделей, которые обычно закрадываются, если кто-то пытается использовать одну и ту же модель во множестве контекстов.

0 голосов
/ 24 декабря 2010

Если вы согласны с примером в Java, это может быть полезно: http://dddsample.sourceforge.net/

...