а, он уже там... ну тогда ладно

Где?)

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

тебе надо делить по функциональным частям.
у тебя нет функциональности Application у тебя есть Comment где внутри у тебя будет Thread и Message.
а вот уже внутри могут лежать папки с названием Read например.

То есть read будет в папках модели?

Рид модель же

Application управляет доменом.
Инфраструктура обеспечивает их репозиториями.

И отдельно read, где внутри лежат реад-можели и репозитории

Ааа. Я вчитался и понял. То что я описал это все лежит внутри папки Comments.

Comments/Application
Comments/Domain
Comments/Infrastructure
Comments/Read

И ещё
Comments/Api - через эти классы другие модули общаются с комментами

Такой себе недомикросервис внутри монолита :)

не стоит употреблять эти термины

какая разница, модули они и в африке модули, связанность она и в африке связанность. кохижен он и в африке ну ты понял

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

Я пока в этом всем плаваю сильно. Но возвращаясь к исходному вопросу...

Код, который обновляет данные для реад-моделек - там же в read должен лежать?

При создании комментария в домене создаётся также событие "создан комментарий" (тригерится оно после сохранения в БД).

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

Такая схема в целом норм?
Если да, то в каком месте должен лежать код, который считает и записывает эти данные...

early return для слабаков)

я бы сложил рядом то что относится к одной и той же функциональности (меняется по схожим причинам) а не "логически" мол репозитории к репозиториям контроллеры к контроллерам. Мол по фичам а не по техническим аспектам. Или "соблюдая SRP формировал пакеты/модули/неймспейсы")

А так - как хочешь так и делай, тебе ж этой структурой пользоваться) можно максимум порекомендоват почитать про information hiding, low coupling hight cohesion

Да, это "сложнее" (надо думать куда положить) но "надо думать" это хорошо

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

Так он от write части вообще никак не зависит,кроме подписки на события