DE
Что значит "неожиданно обнаружится, что это изменило вектор"? Переводя это в плоскость юзеров и емейлов, ты предлагаешь менять в каком-то месте емейл юзеру так, чтобы все остальные места получили старый и уже неактуальный емейл?
В этом и подвох, что при работе с объектами-значениями вроде точек их удобно делать иммутабельными и клонировать. Что если в сервис отправки письма передать клон email-а юзера, чтобы при вызове user.changeEmail этот старый отправленный new Message(user.getEmail()) в этом message.email не поменялся. Это гарантирует корректность старых данных, но вызывает неудобство с поиском актуальных данных.
А в случае с юзером, который в системе и БД имеется один как сущность этот подход весьма спорный. С ним порой удобнее иметь в памяти один объект-синглтон и всем давать возможность дёргать его user.changeEmail. Чтобы в системе и в БД был один и тот же непротиворечивый объект, а не куча клонов юзера с разными почтами, при сохранении перезатирающих друг друга. Это гарантирует единственность и непротиворечивость сущности, но ограничивает горизонтальное масштабирование.
Поэтому в ООП чаще сами сущности делают как раз единственными и мутабельными оркестраторами значений, а объекты-значения делают иммутабельными клонируемыми.
А в случае с юзером, который в системе и БД имеется один как сущность этот подход весьма спорный. С ним порой удобнее иметь в памяти один объект-синглтон и всем давать возможность дёргать его user.changeEmail. Чтобы в системе и в БД был один и тот же непротиворечивый объект, а не куча клонов юзера с разными почтами, при сохранении перезатирающих друг друга. Это гарантирует единственность и непротиворечивость сущности, но ограничивает горизонтальное масштабирование.
Поэтому в ООП чаще сами сущности делают как раз единственными и мутабельными оркестраторами значений, а объекты-значения делают иммутабельными клонируемыми.