И для чего это все - какую пользу несет данное архитектурное решение
для манипуляций над Application требуется много проверок, завязанных на том, какого рода данные пользователь заполнил
я так понимаю у тебя есть некий Application, в котором вся инфа и по всему приложению везде таскаётся этот Application потому что для принятия какихто решений везде нужна какаято инфа оттуда?
нет, Application может быть на разных стадиях и чтобы перевести его в тот или иной статус требуются разнообразные данные пользователя, скажем его возраст и в зависимости от возраста скан паспорта или свидетельство о рожденит и т.п
Все равно не понятно, чем именно помогает тут паттерн Агрегат Есть модуль Application - там есть функции для манипуляции данными: Application и ApplicationData-ми. Эти функции могу использовать функцию генерации id или получать id в качестве аргумента Вообщем похоже что проблема надумана
мне не очень нравится идея генерировать id внутри самой Application, идентичность должен репозиторий выдавать https://matthiasnoback.nl/2018/05/when-and-where-to-determine-the-id-of-an-entity/
вопрос в том, откуда он берётся этот id. Сам id это часть домена, а вот его генерация это уже что-то другое, в моём случае это уже персистенс логика протечёт в домен, т.к id берется из авто-инкремента в какой-нибудь постгрес
логики тут нет - посмотри generateId():integer Где тут логика? Да если ты положишь эту функцию рядом с твоей предметной логикой - то будет "протечка"
Почему плохая?
ну в рантайме у тебя агрегат всё равно в инфраструктуру лезет
Агрегат не знает куда он лезет. Он просто айди получает
Обсуждают сегодня