пользователя не относится к предметной области. Но как тогда валидировать длину пароля, если предметная область будет получать уже готовый хэш? Получается размазывание логики проверки инварианта и анемия.
Еще я видел утверждение у Хорикова, что предметная область должна быть свободна от волатильных и внепроцессных зависимостей. Но хеширование пароля, по моему мнению, внутрипроцессная зависимость и может относиться к типу волатильных зависимостей и то, только в случае если генерится рандомная соль. Но при этом генератор соли можно сделать явной зависимостью и передавать при обновлении пароля.
Еще говорят, что весь алгоритм хеширования нужно делать явной зависимостью. Но а какой в этом смысл если только соль волатильная? Тем более алгоритм хеширования пароля не то, что требуется часто менять, поэтому нет смысла в абстракциях
Еще хеширование не так уж много времени занимает, чтобы стать проблемой при юнит тестировании.
В общем я не понимаю почему хеширование пароля это не предметная область и почему реализация должна быть в инфраструктуре
но алгоритм хэширования может меняться. Хороший пример как сделали в PHP с их password api где у тебя строка с хэшем содержит и соль и указание какой алгоритм юзать и все что надо. И тип вот сча у них апдейт был и они с bcrypt перешли на argon2.
Ну вот он поменялся. Слетели тесты предметной области. Я просто возьму и поменяю реализации setPassword и validatePassword у сущности User и буду дальше использовать bcrypt. А наличия явной зависимости на интерфейсе шифрования не избавило бы от этих же действий
проблема в том что не надо "предметную область" воспринимать как что-то одно. аутентификация - у нее свой под домен и там хэширование пароля может быть частью бизнес логики. Почему бы нет.
Обсуждают сегодня