внезапно это я уже читал)

Ну это в любом случае будет ETL какой. Если все попилено нормально, то ты не сможешь собрать всю необходимую инфу с одной подсистемы, т.к. она же попилена

ну вот а для истории заказа нам не нужен какой примитивный ETL или хотя бы агрегация разных данных из разных подсистем?

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

соответственно "репозиторий заказов" по своей сути не может предоставить нам всех данных которые нужны пользователю (ну либо у нас там ссылки на все и можно вытянуть всю систему через связи в твоей ORM, но это уже UI проникает в persistance)

а если у стейт машины будет только 2 стейта - выполнено и не выполнено - получится хттп адаптер с транзакцией БД 🤔

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

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

нет, не думаю, я просто пытаюсь понять границы, в какой момент что чем становится

так что может регулярки и не стейт-машины)

https://pastebin.com/fVxkNDAY
Это сага или юзкейс?

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

смотри в чем принципиальная разница.

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

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

Что бы все это работало - твой процесс с сагой должен иметь свой стэйт. причем сага должна атомарно работать со своим стэйтом (по сути сага это отличный пример агрегатов) что бы гонки не допускались и вот это все.

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

я про такие юзкейсы

их можно дробить

но основная суть - это те операции про которые ты с бизнесом говоришь. Те операции ивенты которых тебе интересны.

"посмотреть историю заказов" может быть юзкейсом. Просто это может быть класс с кучей SQL и мэппингом на DTO"

Всем привет, поделитесь пожалуйста какими инструментами пользуетесь для описания инфраструктурных схем проектов? При большом количестве сервисов, draw.io выглядит крайне некрасиво и чаще всего похоже на паутину