Я делаю вот так и мне очень стыдно:

На бэкенде:

class UserDto {
  ...
  // если повезёт, тут ещё будет @MaxLength(100)
  // а может ещё доступные символы ограничим
  String firstName;
  ...
}

@Entity
class UserEntity {
  ...
  // тут скорее всего ничего не будет
  @Column(...)
  String firstName;
  ...
}

На фронтэнде:

// если повезёт, ещё будет проверка длины
// а может ещё доступные символы
firstName: new FormField('', Validators.required)  ​

В базе:

​firstName varchar(100) not null

В документации:

firstName - от 1 до 100 символов

Самый настоящий копипаст со всеми вытекающими. Если надо что-то поменять, менять приходится в куче месте. Легко что-то пропустить, в итоге оно разъезжается и вылазят баги. Как вы боретесь с проблемой?

Здравствуйте, rosencrantz, Вы писали:

R>Самый настоящий копипаст со всеми вытекающими. Если надо что-то поменять, менять приходится в куче месте. Легко что-то пропустить, в итоге оно разъезжается и вылазят баги. Как вы боретесь с проблемой?

Эта проблема решена Ричем Хикки в лиспоподобном clojure
все данные представляют собой хеш-мапу

{:name "Alice"
 :age 42}

и в эрланге что-то подобное.
Т.е. в динамически типизированных языках.
Если нужна валидация при преобразованиях то для этого в кложе есть спецификации(не пробовал).
Проблема в том, что мы все еще не знаем как правильно программировать (Хикки).
Лично мое мнение атрибуты явно переоценены, создают жесткую связку.
Больше кол-во дублей от специфики вашего ЯП для того чтобы связать между собой компоненты вам приходится все время преобразовывать данные.
Хуже всего то, что при таких преобразованиях отбрасывается большая часть "не нужных" данных.

Частично это решается более современными технологиями типа wasm или как пример https://safe-stack.github.io/ который благодоря наличию мета-программирования может прозрачно интерполировать
библиотеку типов в js. таким образом избегается большая часть дубляжа. мне в таких штуках не очень нравится сильная завязка на сторонние технологии типа nodejs
Поинтересней blazor(C#) и сабсет fsbolero(F#) на базе Wasm.

Вообщем, тут вопрос каким инструментом вы лучше владеете, тот лучше и выбрать.

Здравствуйте, rosencrantz, Вы писали:

Генераторы используются, задаешь описание в каком-нибудь DSL, на выходе соотв. класс для BL,базы, js и т.д. Логику менять придется уже руками, поэтому бизнес объектах, которые часто меняются хотелось бы ее поменьше.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, rosencrantz, Вы писали:

S>Генераторы используются, задаешь описание в каком-нибудь DSL, на выходе соотв. класс для BL,базы, js и т.д. Логику менять придется уже руками, поэтому бизнес объектах, которые часто меняются хотелось бы ее поменьше.

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

Здравствуйте, rosencrantz, Вы писали:

S>>Генераторы используются, задаешь описание в каком-нибудь DSL, на выходе соотв. класс для BL,базы, js и т.д. Логику менять придется уже руками, поэтому бизнес объектах, которые часто меняются хотелось бы ее поменьше.
R>А для этого есть какие-то готовые инструменты или это просто теоретическое размышление? Понятно, что можно сделать что-то на коленке, но это видится как большая задача с кучей подводных камней.

У меня лично опыта нет, так что да, теоретическое размышление. Но вообще люди пользуются всяческими шаблонами, а долгие проекты\большие организации
пишут подобные штуки для себя. Но вообще не редкость, по классу на c#, например, создать класс на ts. На гитхабе таких проектов
должно быть в избытке.

Здравствуйте, rosencrantz, Вы писали:

R>Я делаю вот так и мне очень стыдно:

R>Самый настоящий копипаст со всеми вытекающими. Если надо что-то поменять, менять приходится в куче месте. Легко что-то пропустить, в итоге оно разъезжается и вылазят баги. Как вы боретесь с проблемой?

Не копипастить. Структура БД не должна содержать бизнес-логику, поэтому констнейты в базе выбираются исходя из технических лимитов, а не бизнес. firstName varchar(256) not null
Бэкенд делает полную валидацию и санирование данных, @MaxLength(100)
А валидация на фронте — это обычный юзабилити, есть валидация — отлично, нет валидации — "server error: firstName length must be less or equal to 100"

Совместить бэковую и фронтовую валидацию многие пытались, но имхо это непрактично. Самое продвинутое из практичного — сервер возвращает результаты валидации на клиент в json по каждому полю на языке пользователя.

Здравствуйте, scf, Вы писали:

scf>Бэкенд делает полную валидацию и санирование данных, @MaxLength(100)

Если нет каких-то особых обстоятельств, зачем делать в базе один размер, а в коде другой?

scf>А валидация на фронте — это обычный юзабилити, есть валидация — отлично, нет валидации — "server error: firstName length must be less or equal to 100"

Такая точка зрения имеет право на жизнь, но здесь многое от целевой аудитории зависит. На моей нынешней работе целевая аудитория глубоко не техническая и они от этого server error гарантированно отложат кирпичей, т.к. ожидают, что в процессе заполнения формочки им сразу скажут где что пропущено, а когда всё будет верно, разблокируют кнопку "отправить" и напишут "да умничка ж ты моя". Можно воспринимать как такой внутренний стандарт.

scf>Совместить бэковую и фронтовую валидацию многие пытались, но имхо это непрактично. Самое продвинутое из практичного — сервер возвращает результаты валидации на клиент в json по каждому полю на языке пользователя.

Пробовал делать почти так — только вместо языка пользователя — именованные коды правил ошибок на каждый аттрибут, а на фронте — маппинги от этих кодов к человеческим объяснениям. Много возни и вот эта вот необходимость всё вбить с ошибками, а потом нажать сабмит, потом только получить объяснение где ты неправ — так себе юзабилити.

Здравствуйте, rosencrantz, Вы писали:

R> Как вы боретесь с проблемой?
По разному. Что первично база или код? Если база, пишется некоторый генератор, который шерстит базу и строит классы на основе таблиц (ну или вьюх, по вкусу), или наоброт, по классам фигачит sql-код для таблиц БД. Ну как-то так. Конечно, есть нюансы, но основное направление такое.

Здравствуйте, rosencrantz, Вы писали:

R>Как вы боретесь с проблемой?

Пишем ДСЛ и генерируем весь нужный код.

Здравствуйте, rosencrantz, Вы писали:

R>А для этого есть какие-то готовые инструменты или это просто теоретическое размышление? Понятно, что можно сделать что-то на коленке, но это видится как большая задача с кучей подводных камней.

Ну, вот мы для этого Nitra сделали и Nemerle. Но в принципе можно и вручную на базе, например, джейсончика. Nitra позволяет сделать ДСЛ с богатым синтаксисом, контролем во время компиляции и плагином к IDE из коробки.