В Implementing domain-driven design можно найти примеры отправки email по доменному событию в application сервисе.
Т.е. отправка email не безнес логика? Если доменный эксперт сказал - после n должно быть отправлено сообщение пользователю, то это разве не должно находить отражение в домене?
Владелец коммерческой компании врядли будет рассказывать о том, как в его бизнесе устроена генерация паролей. Это сугубо технические детали в которых бизнес-аналитик не разбирается и поскольку разработчик моделирует доменную модель реального бизнеса она должна быть лишена подобных технических деталей.
Про реализацию - это понятно. В домене порт(интерфейс) в инфраструктуре адаптер с конкретной реализацией. Опять же если у нас есть задача сгенерировать пароль, то мы вроде как должны это обозначить в домене. Точно так же у репозитория в домене есть метод nextId который реализуется в инфраструктуре, но тем не менее в домене он описан.
Прокинуть зависимость можно в application сервис, там же сгенерировать пароль и уже его передавать в доменную модель.
То есть app сервис будет зависеть от инфраструктурного слоя? или вы имеете ввиду, что в app слое есть порт к инфраструктуре?
Я так понимаю, application слой должен декларировать юз кейсы приложения и содержать координирующую логику, а у вас он довольно много делает.
Верно ли у меня сложилось впечатление, что вы рассматриваете детали подобные сравнению хешей паролей как бизнес-логику и хотите подобные детали инкапсулировать в доменном сервисе?
Нет, действие - логин юзера. Для этого предлагается доменный сервис.