Комментарии 1
Понравилось, это что нужно обсуждать. А то ситуация из разряда: ДДД - это тру, анемичная модель - антипаттерн и, вообще, сама получается, значит обсуждать её не нужно.
Я в своих проектах АПИ использую похожие подходы, но напишу про важное для меня:
Если логики нет или она простая - тестирую через интеграционные тесты. Например, проверяю успешный кейс и то, что можно не пройти валидацию. Все ветви юскейса.
Если в юскейсе есть немного логики, но выносить её в отдельный файл кажется перебором, то делаю её просто статическим методом. Да, публичный статический метод, который нужен только для тестирования. Но т.к. юскейсы вызываются только из конечных точек, то он там никому не мешает.
Все компоненты в DI - статические. Т.е. вся логика не имеет состояния кроме БД.
Если алгоритм проще реализовать через объект с данными, то создаю через фабрику из DI, либо вообще через new по месту использования.
Сервисы с логикой стараюсь делать специализированными, чтобы не было OrderService на 5к строк.
В юнитах почти никогда ничего не мокаю, т.к. чистые функции.
Использую async/await, что является прекрасным маркером есть там ввод/вывод или нет.
Преодоление сложности в самом сердце Анемичной Модели