2 чото не оч понятно о чем речь, по 1 пути бы сделал.

денормализация с целью повышения быстродействия. норм подход.

он о том где это делать

В БД это будет в таблице "thread" в обоих случаях.

Вопрос как сделать на уровне кода.

1) В сущности Thread добавить эти поля и сохраняться будет через ORM.

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

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

Ну то есть второй вариант

2 путь откуда данные будет брать эти? запросом считать?

У репозитория метод addComment, который сохранить в таблицу comment сам комментарий и в таблице thread для ветки обновит поля last_comment_id, comments_count.

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

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

да, выглядит норм. почему у тебя сомнения на этот счет?

Только не давно познал разделение чтение и записи :)
Поэтому пока во многом сомневаюсь

Резонно. Но допустим, что пришли к тому, что денормализировать надо... тогда как лучше сделать?

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

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

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

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

ну и еще вариант - тригеры в базе :)

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

Если событие - очередь - обработка, то получается какое-то время данные будут не консистенты

В одной транзакции по идее должно же бтыь