Так незачем.

Можно не создавать? Разрешаете?

Просто "так повелось" ) Я сам противник таких пустых интерфейсов без всякого смысла. Очень часто такое вижу.

Оправдать можно разве что "чтобы было все в едином стиле". Потому что если у вас есть определенная структура пакетов, и все уже написанные сервисы имеют интерфейсы, которые лежат в определенном пакете и т.д. - то да, новый сервис без интерфейса будет выделяться из паттерна и это будет еще хуже, чем бессмысленное наличие интерфейса. Так что тут меньшее из зол надо выбирать.

Но если такого паттерна нет, то воодить его без причины смысла я не вижу. В 99% случаев у сервисов одна реализация. А если их больше, то это обычно сразу видно. Обычно интерфейсы полезны для кассов в либах, а не в конечном аппликейшен-коде. К тому же, если вдруг в будущем понадобится сделать 2ю реализацию, никто не мешает сделать класс интерфейсом (Extract Interface), а реализацию перенести в новый класс. Вот в этот момент это будет уже оправдано. И вполне обратно совместимо. Особенно если это код конечного приложения, а не либы.

Когда AspectJ юзается для связывания прикомпилции, то сложность создания прокси влияет на время сборки.

Возможно. С compile-time-weaving не работал. Если так, то да, вот ЭТО разумная причина.

Но отличия между интерыейс-неинтерыейс в основном гибкость.
Прокси на всякие final методы вроде и т.п. слету не помню ограничений, пока не нарвёшься, все ок

тоже не люблю когда просто так городится тыща интерфейсов. изза этого пришлось переучиваться и вместо go to declaration тыкать везде go to implementation

я даже как то раз видал совсем маразм когда ДТО покрывали интерфейсами. с такого я ваще в голос ржал

Ха) Да уж. Интерфейс ради интерфейса.
Даже не могу представить, зачем может понадобиться 2 имплементации DTO.. Одна с аннотациями Jackson, а другая.. какой-то другой либы сериализации?..

нет. формулировка была "ну а вдруг что то поменяется"

спорить я не стал, не люблю с такими людьми вообще общаться)

интересно, как наличие интерфейса помогло бы в этом случае)

понятия ваще не имею. вникать не стал)

Не самом деле не просто повелось.
Это подход тотальной инкапскляции.
И при проектировании в таком модходе приятно думать только об интерфейсах, без деталей реализации.
И в TDD, когда дизайн в коде, пишут интерфейсы и заглуш км к ним  в тестах сначала.

Когда уже всё спроектировано вглубь, то интерфейсы действительно как бойлерплейт смотрятся. И интересны толькл для редких апи, где действительно захочется иметь несколько реализаций.

Еще моките вроде легче с интерфейсами жить для юнит-тестов.

На DTO зачем интерыюфейсы? Их даже тестить нечего.
Вот это уже явно лишнее. Просто обьект передачи даных.

Моките точно без разницы. Лишь бы не файнал.

L, возможно и I, смотря как реализовать

Эм, это про механизм автовайринга, а не почему на интерфейсах

Fred, если ты не бот, нажми "восемь". Ботов удалено: 89.

Loader Lous, если ты не бот, нажми "три". Ботов удалено: 89.

Truth Matha, если ты не бот, нажми "четыре". Ботов удалено: 89.

zeus47, если ты не бот, нажми "семь". Ботов удалено: 89.