Если ddd, то общаться с бизнесом :)
Работа с представлением с ddd особо не связана

Достаточно дать возможность подписаться на изменение

Не понял что это значит.

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

Достаточно очевидный факт, что выгоднее работать с изменениями и хранить их отдельно от состояния полученного с сервера(банально потому что оно для фронта всегда валидно, как и домен на сервере). По этому в условном редаксе хранят только не подтвержденные изменения, а запросы просто кэшируют. Так же в Rx два потока изменения и данные с сервера мержат и получают стейт для отображения. Вы также можете хранить изменения для каждого поля модели рядом, и явно обрабатывать изменения применяя различные стратегии обновления для каждого поля, но это редко оправдано.

Можно конечно это все скрыть, но на фронте, даже наверное в большей степени чем на бэке важно знать все переходы состояний, чтобы дать пользователю волшебную кнопочку "назад" в формах, или показывать когда последний раз обновлялись данные которые он видит, и что именно обновилось, и что он отредактировал но ещё не сохранил. В приложениях где этого делать не нужно обычно достаточно просто использовать кэш. И домена в том же плане что на бэке в таких приложениях нет.
PS даже не так, доменом в этом случае являются изменения, а не то состояние которое получено с сервера. Потому что изменения всегда валидны, а при их наложении на ответы от сервера они уже таковыми не являются(только сервер может определить валидность их наложения)

спасибо за развернутый ответ

у меня есть сущность, например Car, у которой есть обязательное свойство Color.
Color маппится на таблицу в бд.
цвет у Car должен быть уникальным, и может быть взят только из существующих.
создать конструктор Car в котором будет свойство Color, и ColorRepository в котором будет метод getFreeColors(): List<Color> и на уровне application работать с этим (?)

это инварианты Car или бизнес правило? (цвет Car должен быть уникальным, и может быть взят только из существующих.)

Всем привет! Подскажите пожалуйста, как лучше начать изучение концепций ООП? Цель, прочитать и понять книгу GoF. Пробовал начать ее, но сложно. Думаю, что бы еще почитать перед ней.

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

Забавно. Именно ее я прочитал где-то на 50%.
В целом ок, но когда начинаются реальные примеры, то становится как-то вяло. Вам так не показалось? Или там, наоборот, вся суть?

я скипал примеры

Понял. Вот и я) Спасибо.
Может еще кто-то ответит

Предлагаю не начинать😅

А то потом начнется: клуб анонимного ООП, раздвоение личности...)

Давным-давно читал Гради Буч и др. "Объектно-ориентированный анализ и проектирование с примерами приложений" - собственно, её уже пару раз посоветовали выше.

Не стоит браться за gof без минимум года практики коммерческой разработки

вообще на стоит браться

Или вообще никогда не стоит:) одержимость шаблонами проектирования до добра не доведёт. Знание их (без понимания зачем они нужны) даст ложное ощущение того, что ты знаешь что делаешь.