Моделі анемічних доменів та введення доменних служб

Модель анемічного домену описується Мартіном Фаулером як анти-модель у дизайні, керованому доменом. Щоб мати ділову логіку на доменних моделях, часто використовують доменні служби. Але введення доменних служб у доменні моделі вважається шкідливим Вон Верноном (див. "Впровадження дизайну, керованого доменом", Сторінка 387).

На мою думку, ці думки суперечливі, чи правда це? Як можна розглядати обидва моменти?

Це дійсно багата доменна модель із введеними доменними службами порівняно з анемічною моделлю домену та звичайними доменними послугами ?

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

Якщо у вас є анемічна модель, ви не повністю використовуєте те, що пропонує OOP. Якщо ви почнете вводити служби в ці моделі, ви, швидше за все, додаєте проблеми, які там не належать. Або це, або ваша модель більш анемічна, ніж ви думаєте. Чому б ще вам потрібна послуга, крім того, що вона пропонує щось необхідне, але відсутнє? (Відсутність може означати анемію.)

Уникнення обох "розповідей" призводить до більш міцного дизайну. Чи є у вас щось у сервісі, яке потребує модель? Можливо, це слід перенести на модель. Якщо ні, можливо, вам слід переглянути свої проблеми. Поведінка моделі повинна працювати всередині моделі. Він повинен головним чином (якщо не тільки) стосуватися себе членів. Але пам’ятайте, все одно знайдуться речі, які працюють над моделлю або з нею. Наприклад, моделі не повинні відкривати TCP-з'єднання або слухати події в інтерфейсі, навіть якщо вони якось пов'язані. Це чужа відповідальність і за те, що хтось ніколи не належить всередині моделі.

Це не суперечливо. Обидва учасники хотіли б, щоб ви ввели свій фактичний код у сам об’єкт домену.

тобто.

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";
    }
}

Відверто кажучи, хоча кожен підхід має свої плюси та мінуси. Той, кого ви обираєте, значною мірою є питанням особистої переваги