Читал чистый код

Чистую архитектуру сложно..

Мне кажется не хватает более базовых вещей. Только каких понять не могу

то есть в системе у нас процесс-менеджер, описанный каким-нибудь декларативным стилем инструкции и бизнес-правилами — что куда и в каком случае идет и как отменяется…

прилетело событие, сага/процесс начала работать
все просто и понятно: шлет команды, хватает события и дальше по флоу гонит…

а в случае, если сага запускается из хэндлеров, а хэндлеры запускаются из Саг — дико сложно как-то выходит

еще раз, я тут самый не опытный по сагам… просто понять хочу

Просто хендлер создания поста сразу у себя запустит:

saga.start(command.id, ...)

вместо запуска в слушателе:

saga.start(event.id, ...)

а зачем хэндлер?
Почему сага сама не может быть хэндлером\слушателем?

Может. Дело вкуса.

Думаю можно ещё пытаться проводить мысленный эксперимент.
Что будет если я удалю папку с модулем?
Если рид модель кушающая ивенты этого модуля будет лежать отдельно - тогда непонятно зачем она(рид модель) осталась - она ведь строится только из ивентов модуля.
Мне кажется к покиданию данных своего модуля нужно относиться очень осторожно. Желание хранить проекцию для каких-то нужд - плохая причина для данных покидать модуль. Потому что это всего лишь проекция данных write-модели.
Можно ещё задать вопрос "Если я переформатировал данные - стали ли они от этого принадлежать другому модулю?"
А вот то что относится к механизму хранения рид-модели - это инфраструктура, это должно быть отдельно. Т.к. какие-то рид-модели могут ещё использовать редис и колоночную бд.

Рид-модель может быть и общая, агрегирующая события из нескольких модулей.

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

Для скорости и для сложных отчётов

Не как шаринг стейта модулей, а как денормализация для чтения

Не думаю, что это достаточное оправдание для шаринга ивентов.
Сложные отчёты - можно юзать application side join.
Что касается скорости - можно определить какая часть отчёта тормозит и сделать кеширование на стороне соответствующего модуля (чтобы данные всё так же не покидали модуль), тогда ботлнека не будет и отчёт станет быстрее.

ХЗ короче, я не знаю на самом деле.
Основной поинт в том, чтобы максимально сопротивляться желанию чё-нить пошарить. Т.к. очень хочется размазать как обычно

ретраи - это общий инфраструктурный момент. Имплементить это каждый раз в саге - это боль. Тут я даже знаю о чём говорю :D

Ну зависит) если инфраструктурно - то повторил и повторил, чего бубнить то? А если важен факт повтора - то я тут повторю конечно, но пометочку поставлю, что такая фигня была, потому что это важно

что значит "важен факт повтора"?
Факт повтора важен только погромисту, чтобы потом посмотреть как часто обработка происходит не с первого раза или там алерт на мыло послать.

Да ну навесил ретраябл реюзабельную абстракцию и радуешься

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