мммм..... а ES тебе никаких гарантий тут не дает)

ну то есть как, зависит от инфраструктуры

ну хорошо, не даёт так не даёт. Сути вопроса не меняет. Это какая-то коварная штука, которую я не могу разрулить

ну типа альтернатива - пихать всё в ивент 🤔

или оценить риски

но это тогда уже не ивент, т.к. инфу пошарили

ну есть ситуации, когда пофиг, может вот как с имейлом. А есть когда нет - тут вариант есть ещё лочить стейт после изменения

тут тебе надо садиться и рисовать потоки данных и смотреть где чего куда откуда и почему.

temporal coupling штука сложная

а где моя волшебня пилюля!

я бы пошло пошутил но

Надо подумать.
Я собирался все это делать после выполнения проекции.

А потом уже с проекцией отправлять письмо.

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

Вот бы спросить у Steam, как они рефанды делают)))

"Valve cannot provide refunds for purchases made outside of Steam (for example, CD keys or Steam wallet cards purchased from third parties)."
получается, что просто не делают

> "outside of Steam"

На самом стиме, можно купить игру, скачать, установить, и потом сделать рефанд

Приветствую :) вот есть ddd и единый язык. Когда аналитики/эксперты/программисты общаются на одном языке, а главное этот язык потом перетекает в код. Но это отлично ложится на жирные агрегаты. Но как я понимаю, лучше строить агрегаты - границы процессов и делать их меньше. Но границы процессов, как то не ложатся на единый язык, это больше деталь реализации кода и не получится общаться с теми эти заказчиками/аналитиками в рамках процессов а не сущностей? Или же подолжать общаться в рамках сущностей, но тогда код не будет отражать единый язык, это норм?

Единый язык на всю предметную область?

Или  единый язык на контекст?