Здравствуйте, #John, Вы писали:

J>Здравствуйте, samius, Вы писали:

S>>То, что не требует мокать — лучше тестируется. Полагаю, что это правда, согласен с автором. Он ведь не утверждает о невозможности.

J>Допустим у нас есть пользователь у него есть контактная информация и нам нужно добавить
J>бизнес логику, когда пользователь нажимает кнопку "Save", нам приходят данные: `Info` и `email` и мы их обрабатываем.

J>В DDD это выглядело бы вот так:

Удивительно рафинированно-анемичный получился пример DDD. Я не вижу в нем ничего, что нельзя было бы выполнить на голом DTO, за исключением, разве что, комментариев
// validation ..
PurchaseItem из статьи был куда более типичен для DDD.
А так же исходный

internal void DoCool(string value, Ac.System system, ILogger logger, IDateTimeProvider, INumberProvider)

или Foo.UpdateStatus с заходом в HttpClient.

J>В трехслойной/четырехслойной архитектуре с анемичными моделями, нам точно так уже пришлось бы мокать `IChangeContactInformationService`
J>и метод "GetContactInformation". Потому разницы в сложности поддержания/написания тестов — нет.

Разница есть и для меня она очевидна. Она в том числе в количестве сущностей, которые придется мокать при взаимодействии множества объектов предметной области между собой.
И в анемике нет нужды мокать вообще все.

J>Бизнес логика в одном месте, работа с данными и все остальное отдельно, все легко тестируется и поддерживается.
Бизнес логики я в этом примере не увидел. Хотелось посмотреть на чуть более сложном примере, где взаимодействуют покупатель, корзина товаров, набор акций на отдельные группы товаров, накопительные бонусные программы или что-то в этом роде.
Я не прошу приводить код, я его довольно ясно представляю, в том числе с тестами и обилием моков.

J>Если придется работать с внешним сервисом, придется создавать DomainService и дробить бизнес логику в rich-моделях.
Проблема рич в том, что чем больше сценариев, тем больше придется дробить бизнес логику в рич моделях.
Та же валидация внутри рич моделей говорит "ой", когда внезапно выясняется, что для одних процессов должна быть одна валидация, а для других — другая.

J>Из дополнительных плюсов с DDD мы легко можем применить CQRS подход.
Сорян, я не вижу причин, почему мы не можем легко применить CQRS подход с анемиком.