так - если ты хочешь вернуть бизнес объект и у тебя там не тупо get(id) - то вопрос как так выходит, почему? почему мы не знаем с чем хотим работать? А если мы хотим вернуть DTO - а как этот дто попал в коллекцию? откуда наш репозиторий узнал про другие данные которые мы никогда в него не клали? Как так вышло что у нас крайне неявный датафлоу в системе и что нам так часто это dto надо рядом с другими методами для БЛ
контрольный вопрос: а если мы делаем маленькие агрегаты (как в той статье которую выше кидали, типа спринты и таски), агрегат таска имеет айди SprintId на родительский агрегат спринта. теперь нам нужно получить все таски для спринта, например чтобы изменить их статус. мы можем поставить в репо в таком случае метод "getForSprint(sprintId)"?
можем, но я бы сделал отдельный сервис где все в sql закатал бы
если батч-процессинг нужен в спринте - можно вытащить пачку идентификаторов тасков для спринта (при помощи SQL) и проводить все транзакции в цикле Или у тебя будет возможность снять галочки у каких-то тасков перед действием и идентификаторы будут прилетать с фронта (то есть всё равно ты будешь получать их при помощи SQL без всяких репозиториев)
"проводить все транзакции в цикле" какие транзакции здесь имеются ввиду? в моем понимании мы вытягиваем 10 тасков в виде уже агрегатов, проходимся по ним, вызываем что то типа task.markCompletedWithComplexBusinessLogic(), и потом всех сохраняем назад?
можно сохранять по одному
Обсуждают сегодня