Ну мой вариант я могу просто командой дергать, чтобы выполнялся sql скрипт какой-нибудь. Я не могу понять вашу задачу. Вы хотите агрегаты, но вы не хотите говорить зачем они нужны

P.S. с памятью все будет хорошо если это по итогу будет чейнинг кверисов через орм, можно и лучше сделать но обычно и так норм

Чет я затупил, применить скидку это просто сохранить ее в скидки кастомера, о какой проблеме тогда вообще речь. Скидка это не скидка заказа, а скидка кастомера.

Я хочу понять как работать с большим объемом данных которые связаны с сущностью, которые как то участвуют в логике. Оптимальный подход, который я вижу, это запросы в бд, но что будет когда в запросе придется повторять бизнес логику

Используй орм, просто сделай так чтобы у тебя был 1 запрос аля "выдавать ли скидку" и потом комитиш скидку в скидки кастомера.

when (priceChanged) {
hasDisc = query.for<Orders>().where(...).agg(_.count() > 4);
if(hasDisc) {
customer.apply(disc);
}
}
И ничего не надо нигде повторять.

Это же просто функция которая принимает какие то данные из заказов за 7 дней и выдаёт значения скидки. И ничего повторять не нужно

Там вопрос который имеет смысл задавать "а могут ли данные которые тебе нужны устареть в процессе и насколько это для тебя важно/опасно". Например кто-то что то поменял (цену, характеристики, скидки) когда ты кому то скидку считал. Вот мол как такие гонки решать. Может быть придется вводить версионирование какое или ещё чего.

+

а как будет выглядеть Order?
как ссылка на Customer и список свойств Order?

у меня не многопоточное

а куда мне получать частичные данные? через dto?

Точно?

точно

я думаю он имеет ввиду что у него эвенты в том же приложении обрабатываются после комита, если это не супер большой апп то вполне норм

так ведь?

вопрос был про два параллельных запроса от двух разных пользователей, они будут всегда выполняться строго последовательно?

ну это понятно нигде не так)

Я не знаю, что вы хотите контролировать в агрегате заказ. Единственное - старайтесь делать их максимально мелкими. Допустим ордер не будет иметь ссылок, он просто будет иметь свойство user_id 5. Тогда проблем с памятью не будет, когда будете вытаскивать все из бд допустим. Пользователь вообще не должен иметь ни ссылок ни айдишников заказов, ибо это ненужная информация в рамках агрегата пользователь, т.к. не имеет правил никаких. Максимум, как я уже сказал - фабричный метод, который будет вам создавать новый агрегат.

ну тогда возвращаемся к проблеме “кто-то что-то поменял, пока я выбирал и считал"

хреновый какой-то совет держать айдишники) зачем, если можно нормально все писать и просто не выбирать данные на клиент когда они не нужны(о орм о нравы)