Я не хочу в thread иметь все комментарии сразу.

Исходя из логики, что мы "добавляем комментарий к теме", а не просто "создаём комментарий".

А как же "автор пишет коммент")?

к теме же пишет

"к теме" может быть просто аргумент с ацдишкой)

Да и влияет ли тема на комент

Тоже верно

class Thread {
  ...
   public function addComment(
        CommentRepositoryInterface $commentRepository,
        int $authorId,
        string $body
    ): void {
        $comment = new Comment($this->getId(), $authorId, $body);
        $commentRepository->save($comment);
    }
  ...
}

короч почитай про Interface Segregation Principle. Смысл в том что бы максимально узкие интерфейсы прокидывать. Мол в этом случае нужно будет что-то типа add.

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

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

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

все так

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

Условно - если мы говорим что "тут нам нужен пользователь и тут нам нужен пользователь" то не всегда это один и тот же "класс".

Да, про разные классы это я осознал уже :) Один из переломных моментов в понимании

Список комментов может быть отдельным и шарить только айди темы

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

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

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

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

Что такое проекция?

Пока просто
Application/ - команды
Domain/ - домен
Infrastructure/ - реализация репозиториев
Read/ - репозитории и модельки для чтения

не надо человека направлять на этот скользский путь