Ну зОчем о грустном ? :(

Ресекьюенсер же паттерн есть.

Вопрос.
Не совсем понял с outbox'ом.
Мы заперсистили доменные эвенты или эвенты на основе доменных в аутбокс перед комитом.

Какие тут могут быть подводные камни?

Тип потом джобой прочитаем, построим и отправим куда нужно?
В чем подвох?

ну вот у тебя два запроса, каждый вставляет ивенты, кто тебе гарантирует что оба проекции строить будут правильно? Что бы такие гарантии были тебе нужен "третий кто-то кто будет стрим читать по изменению всегда в одинаковом порядке"

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

Насчет третьего понял.

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

Так а что тогда по поводу первоначального кейса лучше?


> в случае, когда после бизнес логики мне надо этот же объект отправить в другую апишку JSON'ом условным.
Допустим применить промокод к заказу. Мы через агрегат подпихиваем промокод, а потом нам надо в какой-нить PriceDiscountGateway отдать эту энтитю и получить обратно результат

Кстати...
Я....
Я даже забыл, что есть вьюхи в базе.... 😂
Сижу придумываю гениальные решения по ридмоделям всегда

ну у меня это было бы так:

совершилось какое-то действие - кинулся ивент по коммиту агрегата - по ивенту идем в гейтвей и передаем ему тот кусочек данных который нужен (какие данные - не важно, скорее всего это у меня будет в бэкграунде происходить потому мне надо будет все данные собрать аля как для ui и всегда держать в уме что данные могут устареть). Сходили в апишку, кинули ивент с ответом из апишки. Обработали и т.д. То есть выходит понятная цепочка причина - следствие. Главное не пытаться "реюзать" ивенты и запутывать эту цепочку

благодарю, буду от этого отталкиваться

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

а так если риски делать все синхронно в рамках http запроса не сильно большие я бы сильно думал перед тем как усложнять все

Хорошо.
Если не сложно подскажите еще по одному кейсу:
Когда мы оформляем заказ, у нас есть корзина с товарами.
Нам надо эти товары из корзины "перенести" в заказ. Чтобы они из условных CartItem стали OrderItem. Возможен ли вариант, когда мы в CartItem кладем метод toOrderItem() ?
Или все-таки в CartItem лучше сделать публичными поля, которые необходимы для создания OrderItem'а. В таком случае нам придется из корзины вытаскивать все товары и пересобирать их в OrderItem'ы

я бы toOrderItem делал но скорее всего только по принципу работы (что бы не делать геттеров условно). В целом мне сама идея "копирования" не нравится. мне больше нравится референсы на конкретные ревизии. Но это все от задачи зависит и от того что копируется.

Просто сейчас, если делать именно так, то получается доменный сервис, который у нас собирает из корзины заказ с полями (адрес, все айтемы, номер телефона и т.д.).
Потом условный участок кода.

cartRepository.save(cart)
orderRepository.save(order)

Из-за этого возникла идея, а не сделать ли нам сам заказ агрегатом со ссылкой на корзину собственно, а саму корзину пометить как "Purchased" или что-нибудь в этом роде.

я могу лишь предложить посмотреть видос "Your aggregates are wrong" где как раз разбирают вопросы карзины и заказов и являются ли они агрегатами или нет

ну то есть - тут вопрос "а что вы хотите добиться и зачем вам агрегаты и вот это все". если поиграться - можно ж тогда уже загнаться и разобраться как жить в условиях eventual consistency. А если не хочется eventual consistency не надо гнаться за агрегатами (агрегаты сами по себе всегда консистентны но одна операция может затрагивать их несколько и тут появляются периоды когда два агрегата по отдельности консистентны а вместе стэйт системы невалидный)

еще можно погуглить "Save your repositories from save"