Модель свой стейт контролирует по прежнему

это точно должно быть в phone или в user?

а я бы историю отправленных смс где-то рядом с sender-ом наверное хранил. Во всяком случае если это просто история отправки смс. Ну т.е. она никак не влияет на бизнес логику если 🤔
по идее у инфраструктуры тоже может быть стейт

ну это просто абстрактный пример в вакуме же)

terraform пример) там есть стейт инфраструктуры

Ну он вроде не влияет на ситуацию никак, можно хранить факт отправки, желательно где-то около кода отправки, возможно нужны будут ретраи, возможно это тоже надо будет хранить и все это для кода отправки смски пользователю должно быть крайне не важно, никак не влиять на smsGateway.send(phoneNumber, text)

речь о ситуации что изначально отправка смс не меняла стейт (не имела истории)
реализовали это как
smsGateway.send(user.phone, text) (метод отправки не часть rich model исходя и слов выше)
через какое то время надо было сохранять историю отправленных сообщений, что мы можем ?
1. внутри smsGateway можем генерировать записи
2. Изменить отправку из user.send(smsGateway, text) и уже внутри менять стейт
3. Пройтись по коду и где отправляли смс добавить user.history(text)
4. какие либо другие варианты

можно было сразу нормально написать с интерфейсом а потом декоратор к нему для сохранения истории
интерфейс пишешь в духе gate.notifyUserDidSomething ( user ): Boolean, дальше внутри разберется что делать.
история поверх наворачивается как декоратор
контроль доступа тоже поверх наворачивается как декоратор
количество измененных мест в коде - 1

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

поэтому сначала
- шаг рефакторинга на выделение интерфейса абстракции
- заворачивание в декоратор

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

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

так а что считать правильным, какие критерии?
чего хотим добиться в идеале? "всегО" ? )

вот об этом и речь что способ реализации зависит от целей (требований)

и нет правильно в виде рич модели или анемик модели

имхо

Можно и go-to писать постоянно вместо вызовов функций, if-else-for

А при анемик модели не тот же старый добрый процедурный код получается?

Тот же

Можно фп)