Титанический труд автора и бесценный контент. Как мне его не хватало пару лет назад. Спасибо за труд. По гексоганальной архитектуре мне так же понравилась книга Get Your Hands Dirty on Clean Architecture - там автор тож от теории сразу переходит к практике создания структуры приложения по гексагону, но в книге даже все попрорще, чем в этом видео. В этом видео прям от и до показана структура приложения. И как красиво и просто можно от монолита переходить к распределенным микросервисам. В случае если это действительно понадобилось, а не дань моде.
Не канал, а золотая кладезь знаний. Каждый видос вбирает в себя столько крутых и полезных знаний, что прям вау. Респект тебе, дружище, за такой контент
Мне больше понравился доклад от DDDevotion по чистой архитектуре, но там не показывали процесс разделения на модули и т.п. Я сейчас как раз пишу проект с гексагональной архитектурой, но отдельно на модули его я так и не решился разделить. Спасибо вам за это видео, сегодня постараюсь применить полученные знания)
Спасибо за классный контент. Расскажи плиз что думаешь о Java modules ? Заметил что не используешь в этом тестовом проекте их. Что думаешь над возможностью скрыть часть пакетов с помощью Java modules ?
В целом удобный инструмент, хотя и не решающий всех задач при работе с пакетами, хочется чего-то большего. Вообще код этого проекта распределён таким образом, чтобы не возникло проблем при внедрении JPMS. Но это не продемонстрировано для экономии времени)
Вот интересно, одному мне показалось, что решение слишком переусложнено? По мне, схема, которая используется в большинстве спринг бутовых приложениях вида controller(listener, scheduled и т.д.) -> service -> repository (rest-template, kafka-template и т.д.) работает по тем же принципам, но не переусложнена деталями и допабстракциями. Пока ни разу не сталкивался с гексагоналкой, представленной именно в таком виде. Автору огромное спасибо за разъяснение принципов на практике.
и все-таки какая то магия происходит с produces = "application/vnd.catalogue.product-category.v1+json (в моей редакции без selmag). Запрос GET localhost:8080/api/catalogue/product-categories/1 Accept: application/vnd.api+json (и в других редакциях) возвращает 406 Not Acceptable. Лог Could not find acceptable representation .
А так и должно быть, если метод возвращает "application/vnd.catalogue.product-category.v1+json", то единственное корректное значение заголовка Accept - именно "application/vnd.catalogue.product-category.v1+json"
Отличное видео спасибо Вам большое!!! Тоже использую гексагональную архитектуру, но не разделяю по отдельным модулям порты ведь порты относятся к доменной модели? Может поправите если не так?
Верно ли я понял, что в реализации гексагональной архитектуры нужно под каждый метод класса порта писать отдельный интерфейс? Т.е. порт - это по сути один метод? Или же можно делать порт с несколькими методами?
сложна. восхищаюсь людьми, которые способны держать в голове такие схемы зависимостей (без иронии). но у меня вот вопрос практического свойства: как организовано версионирование модулей? некоторые зависимости встречаются по несколько раз в pom файлах модулей: customer-shared - 6 раз, catalogue-shared - 4 раза, customer-spi-catalogue - 4 раза, catalogue-api - 3 раза. И это у нас всего две бизнес-сущности - Customer и Catalogue, учебный пример! При изменении версии того или иного модуля, как мне кажется, довольно легко забыть внести соответстветствующие изменения во все остальные помники смежных модулей... Вы как с этим справляетесь? Если где-то ошибся или неправильно понял автора, заранее прошу прощения 😇
Обычно нет никаких проблем ручками обновлять версии, но вообще есть плагин versions, который позволяет упростить работу с версиями: www.mojohaus.org/versions/versions-maven-plugin/index.html
Теория рассказано емко и исчерпывающе, но реализация... Сложить каждый класс/интерфейс в свой пакет и обернуть каждый пакет своим модулем, а потом жонглировать модулями - не означает, что вы реализовали гексагональную архитектуру.
Ну, "жонглирование модулями" вообще не про гексагональную архитектуру) Я не совсем правильно выбрал название, сделав акцент именно на гексагональной архитектуре.
Архитектура ради архитектуры.. ну зачем так наворачивать все? Спрингбутовые микросервисы - простая как бревно вещь! Controiller - DTO+Mappers - Service - Repository/Entity Не нужно этих пакетов-модулей-spi-адфптеров.. jdbc еще вынесли куда-то отдельно.. о фак! столько лишних директорий, помников.. глаза болят!!
![🚀Top Technologies to Learn for High-Paying Jobs in 2025 | Future Skills Roadmap [Hindi]](http://i.ytimg.com/vi/1JGPpm7D_TA/mqdefault.jpg)
Титанический труд автора и бесценный контент. Как мне его не хватало пару лет назад. Спасибо за труд. По гексоганальной архитектуре мне так же понравилась книга Get Your Hands Dirty on Clean Architecture - там автор тож от теории сразу переходит к практике создания структуры приложения по гексагону, но в книге даже все попрорще, чем в этом видео. В этом видео прям от и до показана структура приложения. И как красиво и просто можно от монолита переходить к распределенным микросервисам. В случае если это действительно понадобилось, а не дань моде.
Снимай дальше!!! Отличный контент, я бы хотел увидеть ещё про написания правильной веб архитектуры в современном backend
контент супер, было бы круто если бы было продолжение с контейнеризацией
блин, какой же классный контент. Вот нигде такого не видел, если честно.
много спорных моментов, но в комментарии их не укажешь все
Было бы желание)
Не канал, а золотая кладезь знаний. Каждый видос вбирает в себя столько крутых и полезных знаний, что прям вау. Респект тебе, дружище, за такой контент
Спасибище!
«Мне очень не нравятся аббревиатуры в названиях классов», «так называем класс Api, …. следующий класс Spi» 😂
Видео очень интересное, спасибо.
Да, я такой)
красиво!
Спасибо, Александр
уау, сочный контент, посмотрел в захлеб, по теме все делают по разному, увидел еще один вариант реализации))
Очень хочется к вам на индивидуальные занятия, если таковые будите вести.
Про Spring ACL вообще только на этом канале впервые увидел)
Мне больше понравился доклад от DDDevotion по чистой архитектуре, но там не показывали процесс разделения на модули и т.п.
Я сейчас как раз пишу проект с гексагональной архитектурой, но отдельно на модули его я так и не решился разделить. Спасибо вам за это видео, сегодня постараюсь применить полученные знания)
Спасибо за классный контент.
Расскажи плиз что думаешь о Java modules ? Заметил что не используешь в этом тестовом проекте их. Что думаешь над возможностью скрыть часть пакетов с помощью Java modules ?
В целом удобный инструмент, хотя и не решающий всех задач при работе с пакетами, хочется чего-то большего. Вообще код этого проекта распределён таким образом, чтобы не возникло проблем при внедрении JPMS. Но это не продемонстрировано для экономии времени)
Вот интересно, одному мне показалось, что решение слишком переусложнено? По мне, схема, которая используется в большинстве спринг бутовых приложениях вида controller(listener, scheduled и т.д.) -> service -> repository (rest-template, kafka-template и т.д.) работает по тем же принципам, но не переусложнена деталями и допабстракциями. Пока ни разу не сталкивался с гексагоналкой, представленной именно в таком виде. Автору огромное спасибо за разъяснение принципов на практике.
Слоистую архитектуру люди научились варить)
А вот с гексагональной и ддд у большинства проблемы с пониманием + каждый по своему трактует
И там и там есть плюсы и минусы. Иногда классическая трехслойка в одном модуле будет предпочтительнее.
Однозначно лучший джавист
Да ну нееее... Но спасибо)
Где же найти столько свободного времени чтоб это всё посмотреть ?))
Ну, яж нашёл как-то время это всё записать)
@@shurik_codes спасибо большое
Продолжайте
Мы обязательно все посмотрим )
большое спасибо автору
и все-таки какая то магия происходит с produces = "application/vnd.catalogue.product-category.v1+json (в моей редакции без selmag). Запрос GET localhost:8080/api/catalogue/product-categories/1 Accept: application/vnd.api+json (и в других редакциях) возвращает 406 Not Acceptable. Лог Could not find acceptable representation .
Не. Магии нет. Не было getter-ов в ProductCategoryPresentationV1
А так и должно быть, если метод возвращает "application/vnd.catalogue.product-category.v1+json", то единственное корректное значение заголовка Accept - именно "application/vnd.catalogue.product-category.v1+json"
🔥🔥🔥
Подскажите, как реализовать с JPA. Где должны располагаться сущности и располагаться миграции?
Александр, большое спасибо за видео. Получается, можно обойтись без доменной сущности, которая в ядре была?
В операциях чтения - да
👍
Отличное видео спасибо Вам большое!!! Тоже использую гексагональную архитектуру, но не разделяю по отдельным модулям порты ведь порты относятся к доменной модели? Может поправите если не так?
Ну, домен делится на ограниченные контексты, которые реализуются в виде модулей, а каждый порт относится к тому или иному ограниченному контексту.
Верно ли я понял, что в реализации гексагональной архитектуры нужно под каждый метод класса порта писать отдельный интерфейс? Т.е. порт - это по сути один метод? Или же можно делать порт с несколькими методами?
Можно писать и несколько методов в одном порте, никто не запрещает. Я просто так трактую принцип разделения интерфейса.
Code Complexity - какой профит от этого плагина?
Оценка когнитивной сложности, ставил ради интереса
сложна. восхищаюсь людьми, которые способны держать в голове такие схемы зависимостей (без иронии). но у меня вот вопрос практического свойства: как организовано версионирование модулей?
некоторые зависимости встречаются по несколько раз в pom файлах модулей: customer-shared - 6 раз, catalogue-shared - 4 раза, customer-spi-catalogue - 4 раза, catalogue-api - 3 раза. И это у нас всего две бизнес-сущности - Customer и Catalogue, учебный пример!
При изменении версии того или иного модуля, как мне кажется, довольно легко забыть внести соответстветствующие изменения во все остальные помники смежных модулей... Вы как с этим справляетесь?
Если где-то ошибся или неправильно понял автора, заранее прошу прощения 😇
Обычно нет никаких проблем ручками обновлять версии, но вообще есть плагин versions, который позволяет упростить работу с версиями: www.mojohaus.org/versions/versions-maven-plugin/index.html
А кто может подсказать, что за плагинчик под идею с @simple 0%? Это про конгитивную сложность кода что-то?
Code Complexity
Не показывайте это КРУДОделам, у них инфаркт случится
Один глаз на нас, другой на Кавказ.
А видос - класс)
Ох уже эти ваши шуточки про мои глаза...
Теория рассказано емко и исчерпывающе, но реализация... Сложить каждый класс/интерфейс в свой пакет и обернуть каждый пакет своим модулем, а потом жонглировать модулями - не означает, что вы реализовали гексагональную архитектуру.
Ну, "жонглирование модулями" вообще не про гексагональную архитектуру) Я не совсем правильно выбрал название, сделав акцент именно на гексагональной архитектуре.
Так расскажи
Архитектура ради архитектуры.. ну зачем так наворачивать все? Спрингбутовые микросервисы - простая как бревно вещь! Controiller - DTO+Mappers - Service - Repository/Entity
Не нужно этих пакетов-модулей-spi-адфптеров.. jdbc еще вынесли куда-то отдельно.. о фак! столько лишних директорий, помников.. глаза болят!!