В докладе озвучены проблемы, связанные не столько с самим value object, сколько с валидацией, персистенцией и управлением изменениями. Если вы персистете entity, то безопасным изменением будет только добавление нового поля. Любое изменение уже существующего влечет контролируемую миграцию. Даже если вы не используете value object, или валидацию через JSR303, и лишь немного поменялось назначение поля без изменения формата, нужно исследовать все эффекты, которые может дать это изменение.
30:50 Точно так же можно данные сложить в объект. Просто преобразованием/валидацией сырых данных будет заниматься не конструктор/статический метод, а сервис/фабрика.
Практически все значения могут стать невалидными, особенно если не продумать ограничения в самом начале, и потом исправить это будет очень сложно, даже если вы данными владеете. Если от ваших данных кто-то сильно зависит, то это отдельная проблема сама по себе. Значения не обязательно должны быть максимально валидными, плюсы от их использования сохраняются. Дополнительная валидация понадобится в любом случае, если данные будут пересекать границы системы.
Соглашусь с комментариями выше и добавлю. Недавно смотрел лекции на Dddevotion там был классный пример в котром персистетный уровень разделен с уровнем бизнес логики и все value object были именно в слое бизнес логики, это дает преимущество в том что если менять бд с постгрес на монгу например то это никак не коснется уровня бизнес логики. Там была смесь ddd и clean architecture.
В докладе озвучены проблемы, связанные не столько с самим value object, сколько с валидацией, персистенцией и управлением изменениями. Если вы персистете entity, то безопасным изменением будет только добавление нового поля. Любое изменение уже существующего влечет контролируемую миграцию. Даже если вы не используете value object, или валидацию через JSR303, и лишь немного поменялось назначение поля без изменения формата, нужно исследовать все эффекты, которые может дать это изменение.
30:50 Точно так же можно данные сложить в объект. Просто преобразованием/валидацией сырых данных будет заниматься не конструктор/статический метод, а сервис/фабрика.
Практически все значения могут стать невалидными, особенно если не продумать ограничения в самом начале, и потом исправить это будет очень сложно, даже если вы данными владеете. Если от ваших данных кто-то сильно зависит, то это отдельная проблема сама по себе. Значения не обязательно должны быть максимально валидными, плюсы от их использования сохраняются. Дополнительная валидация понадобится в любом случае, если данные будут пересекать границы системы.
О чем тема? Смешать слой бд и бизнес валидацию и пытаться в этом найти положительные моменты? Бессмыслица какая то
всё выступление думал об этом
Соглашусь с комментариями выше и добавлю. Недавно смотрел лекции на Dddevotion там был классный пример в котром персистетный уровень разделен с уровнем бизнес логики и все value object были именно в слое бизнес логики, это дает преимущество в том что если менять бд с постгрес на монгу например то это никак не коснется уровня бизнес логики. Там была смесь ddd и clean architecture.
у меня так на проекте, есть 3 вида моделей dto,model (в логике) и entity
Value Object надо относится как к enum, и уж темболее не перекладывать всю валидацию в него.