Всем доброго дня. Прошу разъяснить такой момент, когда я подключаю Hibernate к проекту, мне необходимо содавать конфигурацию (Пример: Configuration configuration = new org.hibernate.cfg.Configuration();) А теперь вопрос, эту конфигурацию я должен указать в мейне?

Привет.
Подскажите как для Jackson пометить что некоторые поля опциональны(или все если на уровне класса есть такая анотация)

Привет.
Подскажите как для Jackson пометить что некоторые поля опциональны(или все если на уровне класса есть такая анотация)

А зачем?

Я тоже задумывался о надобности Interface -> Impl.
Читал solid. Я так понял, что  имели ввиду, что если есть интерфейс и impl, то правильно поменять impl на другой impl в случае, когда нужно изменить логику в impl. Но по сути никто не парится и меняет сразу код в impl. Если так большинство делает, то зачем эти интерфейсы для сервисов и компонентов реально нужны? К слову, у нас на прошлом проекте все взаимодействия были через методы интерфейсов, жуть

разделение ответственности между чем и чем?
интерфейсы - это не про разделение ответственности, а про сокрытие и замену имплементации

Ок, параллельно со спором "мало топиков и много типов сообщений в топике" vs "топик на так сообщения" есть ещё "определенные сообщения в определенные топики vs топик на сервис", рассмотрим его

В обоих случаях есть плюсы и минусы, для первого плюс - за сообщением закреплены топики (обычно один), ты просто в него шлёшь и все, но возникает проблема (минус) - всем ли потребителям нужны все сообщения этого типа?

Для второго типа картина другая, если сообщение попало в топик, значит оно нужно клиенту, это плюс - ведь не надо решать сервису оно нужно или нет, просто станет и обрабатывает, но есть и минус - отправитель должен решить кому нужно это уведомление. Для решения этой проблемы есть паттерн ESB(enterprise service bus), это координатор, ты ему все сообщения сваливаешь в топик и он уже решает кому в какой топик их послать. Минус тут в том, что логику кому нужно сообщение все равно писать, только в ESB, обычно для этого делают систему адресации, дополняют сообщения метаинформацией и т.д.

Как по мне все таки первый вариант проще и лучше, пусть сообщения определенных типов летят в определенные топики, пусть сервисы читают интересующие их топики, к тому же случай, когда сервису нужны не все сообщения типа бывает очень редко и сервис способен самостоятельно решить все. Городить адресацию с ESB не легко и требуется это в очень ограниченном количестве случаев, например при взаимодействии уже между системами, а не сервисами внутри системы

разделение функциональности по интерфейсам, сервис в итоге может реализовывать несколько