Есть холиварный вопрос, по поводу если у нас Entity совпадает с DTO, то стоит ли вообще делать DTO, если мы можем все на уровне Jackson-а разруливать.

Просто если мы вводим понятие DTO, и наш сервис будет как слой возвращать только его, то при обращении из сервиса сервис нужно конвертировать постоянно (Entity<->DTO) и использовать репозитории + нам придется писать какую нибудь дублирующуюся логику (например для проверки сущтвования сущности).

Имеет смысл выности преобразование на уровень контоллеров, чтоб избавиться от этого или вообще писать DTO? Хотя есть боязнь, что потечь может...

Есть холиварный вопрос, по поводу если у нас Entity совпадает с DTO, то стоит ли вообще делать DTO, если мы можем все на уровне Jackson-а разруливать.

Просто если мы вводим понятие DTO, и наш сервис будет как слой возвращать только его, то при обращении из сервиса сервис нужно конвертировать постоянно (Entity<->DTO) и использовать репозитории + нам придется писать какую нибудь дублирующуюся логику (например для проверки сущтвования сущности).

Имеет смысл выности преобразование на уровень контоллеров, чтоб избавиться от этого или вообще писать DTO? Хотя есть боязнь, что потечь может...

стоит следовать принципам SOILD -> разделять объект предназнченный для хранения в БД и объект для внешних клиентов

Просто тут вопрос в том, например у нас пришла сущность DTO с двувумя Id  

class A {
  Long id;
}

class B {
  Long id;
}
class ABDTO {
  Long aId;
  Long bId;
}

И мы к примеру обращаемся в сервис ABService

Так бы можно было бы просто вызвать из сервиса сервис, т.е. aService.getById(...) - и там уже есть обработка данной ошибки если сущность не найдена и не надо писать тут какие то дополнительные проверки.

ну у вас будет сервис, который в себе содержит 2 других сервиса и юзает их, не в контроллере же этим заниматься

Это понятно, только если сервис возвращает DTO то там еще преобразований куча

Есть холиварный вопрос, по поводу если у нас Entity совпадает с DTO, то стоит ли вообще делать DTO, если мы можем все на уровне Jackson-а разруливать.

Просто если мы вводим понятие DTO, и наш сервис будет как слой возвращать только его, то при обращении из сервиса сервис нужно конвертировать постоянно (Entity<->DTO) и использовать репозитории + нам придется писать какую нибудь дублирующуюся логику (например для проверки сущтвования сущности).

Имеет смысл выности преобразование на уровень контоллеров, чтоб избавиться от этого или вообще писать DTO? Хотя есть боязнь, что потечь может...

ну во первых, вам никто не запрещает из сервиса возвращать entity , во творых никто не запрещает заимплементить логику прямо в сервисе А/B если это возможно, сервис это как правило не просто прослойка между контроллером и репозиторием/дао

Просто хотелось бы как то изолировать тогда возрат DTO и общение с контроллерами, но и также сделать нормальную работу с Entity на уровне сервисов