вот здесь вот код с abstract function getLogger(): LoggerInterface;
не понятно как к нему относиться
мне не нравится тем, что в дочернем классе могут на реализацию забиндиться, но с другой стороны - это же не моя проблема? или моя?
если я разрешаю что-то сделать не правильно - я плохо поступаю?

да, с примера наше общение и началось
я написал ей, что пример косячный и лучше через интерфейс, а она мне и начала говорить, что у нее все верно и у нее dip даже в этом случае

Да, нельзя разрешать делать хуйню, в этом смысл архитектуры

А ее пример выглядит каким-то говном

У меня тоже непонимание.

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

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

Еще говорят, что весь алгоритм хеширования нужно делать явной зависимостью. Но а какой в этом смысл если только соль волатильная? Тем более алгоритм хеширования пароля не то, что требуется часто менять, поэтому нет смысла в абстракциях

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

В общем я не понимаю почему хеширование пароля это не предметная область и почему реализация должна быть в инфраструктуре

аутентификация как правило generic домен и вообще юзай from the shelf software

но алгоритм хэширования может меняться. Хороший пример как сделали в PHP с их password api где у тебя строка с хэшем содержит и соль и указание какой алгоритм юзать и все что надо. И тип вот сча у них апдейт был и они с bcrypt перешли на argon2.

> Еще я видел утверждение у Хорикова, что предметная область должна быть свободна от волатильных и внепроцессных зависимостей.

тебе не платят за чистоту модели. А креды это оч маленькая самодостаточная штука которая должна быть изолирована от остальных контекстов системы

Всем привет, а сейчас в 2022 году по прежнему подход DDD будет актуален?
Кто как думает?

пришло время анемичных моделей и сервисов

Так же актуален как и в 1960-х

Микросервисов?

Ясно

Ну вот он поменялся. Слетели тесты предметной области. Я просто возьму и поменяю реализации setPassword и validatePassword у сущности User и буду дальше использовать bcrypt. А наличия явной зависимости на интерфейсе шифрования не избавило бы от этих же действий

Ну смотря какой смысл ты вкладываешь в ddd

Ну да, это другой контекст. Но этот контекст тоже можно организовать, выделить предметную область

что бы грамотно декомпозировать систему тебе нужен анализ предметной области. Можешь называть это DDD, можешь называть это "identifing operational and development value streams" как это делают челы из scaled agile framework или "ищем потоки изменений требований" из teams topology

ddd это не про код в конце концов, это про то как разделить сложную систему на куски и выбрать каждому куску актуальную модель. А вот этот весь булшит про сущности репозитории - это все вторично

Ну, вроде проясняется

в этом ключе в DDD ничего нового. как в 60-х 70-х писали про informaation hiding кка критерий для декомпозиции систем (что бы можно было разных людей на разные куски садить так что бы люди могли более автономно принимать решения и более эффективно работать) так и сейчас. Сейчас это просто больше встречается в силу всяких там модных лямбд и прочих сервелесс (чуть стратегия прайсинга за инфраструктуру меняется). Это как devops - ничего нового, просто хэштег в твитторе

Devops значит - это дело все называется)