Где разместить бизнес-логику в DDD

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

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

Однако некоторые люди сказали, что это антипаттерн и что бизнес-логику не следует реализовывать на уровне сервисов. Почему это?

Допустим, у нас есть IAuthenticationService , у которого есть метод с bool UsernameAvailable (string username) подписью. В методе будет реализована вся необходимая логика для проверки, доступно ли имя пользователя.

В чем проблема, согласно толпе «это антипаттерн»?