и с какой целью ты это дело разделял

Я думал в до будет много логики, а аннотации орм были бы сильно некрасивы. Сейчас же мне кажется, что я несколько ошибался и в до как-то пока особо нет логики Структуры довольно похожи. Правда в паре мест нужно было чуть более хитро смапить одно на другое, но отличия совсем небольшие, по факту

насколько они отличаются?

и что надо сделать, чтобы скажем поле добавить или переименовать)

так, ну вот что вы начинаете это вот всё! ) с переименованием IDEA почти справляется а с добавлением, кроме добавления поля в таблицу и в ДО — добавить в модель. если поле «простое», то, как бы и всё. маппер сам «подцепит».

так, ну вот что вы начинаете это вот всё! ) с переименованием IDEA почти справляется а с добавлением, кроме добавления поля в таблицу и в ДО — добавить в модель. если поле «простое», то, как бы и всё. маппер сам «подцепит».

а приведи примеры "непростых" полей

со странными связями. вот вчера нарвался проект. в проекте общий список свойств. также в проекте есть List<Foo> в Foo в свою очередь List<Bar> а в Bar список сущностей, в которых лежит экземеляр свойства и его значение чтобы это смаппить нужно проходить руками в @Aftermapping

так, ну вот что вы начинаете это вот всё! ) с переименованием IDEA почти справляется а с добавлением, кроме добавления поля в таблицу и в ДО — добавить в модель. если поле «простое», то, как бы и всё. маппер сам «подцепит».

ну то есть идея какая.... есть ситуации когда у тебя переименовывание полей в базе частое явление и хочется обезопасить DO от изменения - тогда как бы логично это дело разделить как-то. Но как правило это не так и обычно штуки типа изменение схемы и т.д. идут рука обруку с изменением DO. Особенно если у тебя какой-нибудь постгрес или документно ориентированная база

и тогда как бы профит от разделения становится не таким существенным (он все еще может быть, и все в язык упирается и в доступные инструменты). Ну и самое отстойное когда люди загоняются по слоям - у тебя разные части приложения могут иметь разные потребности в плане разделения по слоям и в итоге у тебя будет неоптимальное соотношение гибкости и удобства разработки.

часов за шесть переделал. кажется, в коде стало логичнее а в каком месте более красиво делать проверку при обновлении агрегата, прилетевшего в виде DTO? с корнем понятно — его можно прям на входе проверить, когда DTO только прилетел а как быть с остальной требухой? ведь можно злонамеренно подменить id каких-то внутренних структур и получить после сохранения нечто странное. загрузить модель из базы и в маппере (при обновлении модели перед сохранением) проверять, чтобы не появилось сущностей с id, которых нет в модельке?

CLOS

часов за шесть переделал. кажется, в коде стало логичнее а в каком месте более красиво делать проверку при обновлении агрегата, прилетевшего в виде DTO? с корнем понятно — его можно прям на входе проверить, когда DTO только прилетел а как быть с остальной требухой? ведь можно злонамеренно подменить id каких-то внутренних структур и получить после сохранения нечто странное. загрузить модель из базы и в маппере (при обновлении модели перед сохранением) проверять, чтобы не появилось сущностей с id, которых нет в модельке?

Что значит прилетевший агрегат? Это доменная часть его запрашивает?

Что значит прилетевший агрегат? Это доменная часть его запрашивает?

(может быть я неправильно употребил термин агрегат перестаёт быть агрегатом если его куда-то смапили? или если нарисовали на бумажке) нет, не доменная. прилетает DTO из фронтенда и в нём лежит информация для обновления агрегата, структурно его повторяющая