Анемичные доменные модели и внедрение доменных сервисов

19

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

На мой взгляд, эти мнения противоречивы, правда ли это? Как можно рассмотреть обе точки?

Действительно ли это богатая модель домена с введенными службами домена по сравнению с моделью анемичного домена и обычными службами домена ?

domain-driven-design dependency-injection services

— Sjoerd222888
источник

4

Я ни в коем случае не эксперт в этом, но я думал, что тип логики, которая входит в доменные сервисы и в доменные сущности, принципиально отличается. Логика, которая входит в сущности, - это логика, необходимая для поддержания объекта в правильном состоянии. Это включает в себя проверку и преобразование логики. Доменные службы, с другой стороны, предназначены для логики более высокого уровня. Так, например, доменная служба будет моделировать бизнес-процесс, который включает в себя несколько различных типов объектов сложными способами.

— MetaFight

2

@MetaFight: даже если бизнес-процесс оказывает сложное воздействие на несколько объектов, вы можете достичь этого без услуг, если у вас есть хорошая модель совокупного корневого домена, то есть модель домена, которая имеет доступ ко всем затронутым объектам в виде свойств или полей.

— Грег Бургхардт

Это имеет смысл :)

— MetaFight

16

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

Если у вас анемичная модель, вы не совсем понимаете, что предлагает ООП. Если вы начнете внедрять сервисы в эти модели, вы, скорее всего, будете внедрять проблемы, которые не относятся к ним. Либо это, либо ваша модель более анемична, чем вы думаете. Зачем еще вам нужна услуга, отличная от той, которая необходима, но отсутствует? (Отсутствие может означать анемию.)

Избегание обоих «говорит» приводит к более сильному дизайну. Есть ли у вас что-то в сервисе, в котором нуждается модель? Может быть, это следует перенести на модель. Если нет, возможно, вам следует пересмотреть свои проблемы. Поведение модели должно работать внутри модели. Это должно главным образом (если не только) заботиться о членах. Но помните, что все еще будут вещи, которые работают на или с моделью. Например, модели не должны открывать соединения TCP или прослушивать события пользовательского интерфейса, даже если они каким-то образом связаны. Это чужая ответственность , и что кто - то никогда не принадлежит внутри модели.

— Скудный Роджер
источник

7

Хорошее различие, которое мне нравится помнить, состоит в том, что ваша модель домена реализует бизнес-логику, а ваши доменные службы выполняют бизнес-логику на моделях домена. Разница в том, кто кому звонит. Службы могут вызывать методы модели домена. Если доменные модели вызывают методы Service, вы перевернули шаблон поверх его головы.

— Грег Бургардт

7

Это не противоречиво. Оба сторонника хотели бы, чтобы вы поместили свой фактический код в сам объект домена.

то есть.

public class Order
{
    private string status = "not bought";
    public void Buy()
    {
        this.status = "bought";
    }
}

против ADM

public class Order
{
    public string Status = "not bought";
}

public class BuyingService
{
    public Order Buy(Order order)
    {
         Order o = new Order();
         o.status = "bought";
         return o;
    }
}

против введенных услуг

public class Order
{
    public Order(IBuyingService bs)
    {
        _bs = bs;
    }
    private IbuyingService _bs;
    private string status = "not bought";
    public void Buy()
    {
        this.status = _bs.Buy();
    }
}

public class BuyingService : IBuyingService
{
    public string Buy()
    {
         return = "bought";
    }
}

Честно говоря, хотя у каждого подхода есть свои плюсы и минусы. Тот, который вы выбираете, во многом зависит от личных предпочтений

— Ewan
источник