Есть, много.

если агрегат документ то не может быть "100500" запросов.

Вообще агрегаты должны быть оч маленькими. Это партиция данных по которым ты можешь операции паралелить. Чем они больше - тем больше вероятность коллизий и тем меньше пропускная способность системы.

Подозреваю что мы опять юзаем термины не договорившись что они значат и в твоем случае "агрегат" это просто "куча данных".

Пример я привел - спецификация товара у крупного ритейлера. На производстве есть маршрутные и операционные карты.

Что насчёт получения и обработки нескольких сущностей? Отдельно отчёт и отдельно репозиторий с получением сущности по ИД-шке?

окей, не понятно что твой пример подразумевает - надо "показать" это пользователю или все эти данные - все те 100500 данных что ты достаешь влияют на инварианты? Если показать - то это не интересно, джойны и SQL справятся. Если "надо все менять и все данные влияют" - значит разбираться какие инварианты есть и какие из этих вариантов являются true invariants

Ессно влияют. И на показ влияют. Элементы спецификации не живут вне спецификации. Выдать пользователю спецификацию, тем более для модификации, значит выдать все её элементы.

Да, еще доступ надо проверять ко всем элементам.

Уточни что ты подразумеваешь под "обработкой нескольких сущностей".

Условно - batch операции. Аля опубликуй все неопубликованное - тут можно достать список неопубликованного и операцию ты будешь в любом случае делать "отдельно для каждого". Ну или у тебя будет условный table gateway который флажек через базу поставит, это уже как бы за рамками вопросов "repository pattern".

если "надо достать и чуть трансформировать данные что бы выплюнуть на UI" - тут есть оч важный аспект - стэйт системы при этом не меняется соответственно количество вариантов как чего делать растет. Мы не паримся на тему того что референсы на объекты какие-то не такие, мы не паримся что дублирование данных и денормализация - как удобно так и делай. Поскольку нет изменений стэйта и поскольку в любом случае все что будет смотреть пользователь на UI "уже устарело в момент когда сигнал дойдет до мозга".

смешались в кучу кони люди

на тему "устаревания данных" - интересный факт - мозг не воспринимает время как абсолютную точку. Мы когда информацию воспринимаем учитываем "небольшой буфер" что происходило до и докручиваем что бы все события (звуки, визуальная информация) совпадали. Просто любопытный факт.

Вопрос про batch-операции, да

ну по дефолту - узнали айдишки челов с которыми надо провести операции - по одному провели. Этого хватает для 80-90% кейсов. Особенно там где операции эти можно делать "по отдельности". Тогда у тебя реализация остается консистентной для каждого кейса.

Есть оч редкие операции к которым больше требований в плане "надо быстро" - тут можно думать. Универсальных рецептов нет и как я сказал - тут только если мы мысленно представляем что наш репозиторий это на самом деле table gateway

@fes0r А узнаём АЙдишки мы как, какой-нибудь PostReport.lastIds() сделать?

зачем lastIds?

хотя все это есть в публикации 70-х на тему information hiding

Ну какой-нибудь отчёт который возвращает идентификаторы

идентификаторы того что уже удалено потенциально)

ну если удалено ну ничего страшного) partial failure все дела... всегда ж надо такое в batch операциях хэндлить

Есть способы работать только с тем что не удалено?