А конвертите дто в ентити на каком слое? Т.е что принимают методы сервисов дто или ентити?

Просто здесь в ссылке баелдунга, как раз из сервиса приходит ентити post, а потом в контроллере post в postDto идет

LocalDTO
https://martinfowler.com/bliki/LocalDTO.html

Вот, насколько я понимаю, здесь как раз речь, о том что дто нужно для удаленных вызово, чтобы не гонять весь кучу байт по сети, и о том что дто в контексте приложения не гуд. Not just do you not need them in a local context, they are actually harmful both because a coarse-grained API is more difficult to use and because you have to do all the work moving data from your domain or data source layer into the DTOs. Или я неправильно понимаю эту статью?

Все правильно понимаете

Если в каком-то случае понадобятся легкие структуры, можно найти кучу вариантов именования и без ДТО

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

Мне очень нравится концепция чистой архитектуры Мартина(гексогональной и тд). Контроллеры только адаптеры над вызвом апи(порты). Апи принимает дто и не раскрывает свою доменную модель. Внутри сервисы могут работать уже с доменной моделью и даже сущностями(entity), контроллеры не узнают об этом. Транзакция также внутри, не выходит в контролёр.
Этот подход позволяет вызвать приложения как по рест, так по другим транспортам, сделав адаптер над портом

Тут я пожалуй согласен с Дмитрием. Лучше не выдавать сущности из сервисного слоя... по ряду причин. Максимум легкосерализуемые иммутабельные объекты-значения. На счет общей логики и разных контроллеров не совсем понял

Да, мне тоже это нравится, но получается на сущность может быть очень много моделей, дто, антити и доменная модель, и еще я не совсем понимаю, чем отличается ентити от доменноц модели, я думал что это одно и тоже, почитаю.

Советую тогда  это почитать -
https://www.goodreads.com/book/show/49238827-get-your-hands-dirty-on-clean-architecture
очень практичное описание хексагональной архитектуры  с примерами кода на гитхабе

Спасибо, ознакомлюсь

Ребят какое можно добавить исключение в кейсы и свитч по типу RuntimeExeption ArithmeticalExeption

наверное догнать в фичах. Но даже с текущим состоянием не верю, что массы уйдут со спринга. С j8, бл.., уйти не могут

Существует 2 разные ентити: JPA @Entity и DDD Entity. И то и другое может использоваться в качестве доменной модели. По DDD их разделяют: DDD Entity - доменная модель, JPA @Entity - структура персистентного слоя

Спасибо за пояснение) получается, тогда я могу работать с доменной моделью, а потом ее конвертить в ентити и сохранять, допустим, верно?

Да, как вариант

Просто получается слишком много классов, дто на вход, потом домен, потом ентити, ужс) а еще, допустим если у меня структура того что я отдают на фронт и ентити совпадает, почему плохо отдать ентити? Чтобы не плодить не нужные абстракции, вроде в этой статье которую я скинул, фаулер как раз об этом говорит

На счет большого количества классов это да, цена которую мы платим за чистую архитектуру (What data crosses the boundaries. - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)