Вот интересно, одному мне показалось, что решение слишком переусложнено? По мне, схема, которая используется в большинстве спринг бутовых приложениях вида controller(listener, scheduled и т.д.) -> service -> repository (rest-template, kafka-template и т.д.) работает по тем же принципам, но не переусложнена деталями и допабстракциями. Пока ни разу не сталкивался с гексагоналкой, представленной именно в таком виде. Автору огромное спасибо за разъяснение принципов на практике.
Титанический труд автора и бесценный контент. Как мне его не хватало пару лет назад. Спасибо за труд. По гексоганальной архитектуре мне так же понравилась книга Get Your Hands Dirty on Clean Architecture - там автор тож от теории сразу переходит к практике создания структуры приложения по гексагону, но в книге даже все попрорще, чем в этом видео. В этом видео прям от и до показана структура приложения. И как красиво и просто можно от монолита переходить к распределенным микросервисам. В случае если это действительно понадобилось, а не дань моде.
Мне больше понравился доклад от DDDevotion по чистой архитектуре, но там не показывали процесс разделения на модули и т.п. Я сейчас как раз пишу проект с гексагональной архитектурой, но отдельно на модули его я так и не решился разделить. Спасибо вам за это видео, сегодня постараюсь применить полученные знания)
Не канал, а золотая кладезь знаний. Каждый видос вбирает в себя столько крутых и полезных знаний, что прям вау. Респект тебе, дружище, за такой контент
Спасибо за классный контент. Расскажи плиз что думаешь о Java modules ? Заметил что не используешь в этом тестовом проекте их. Что думаешь над возможностью скрыть часть пакетов с помощью Java modules ?
В целом удобный инструмент, хотя и не решающий всех задач при работе с пакетами, хочется чего-то большего. Вообще код этого проекта распределён таким образом, чтобы не возникло проблем при внедрении JPMS. Но это не продемонстрировано для экономии времени)
Верно ли я понял, что в реализации гексагональной архитектуры нужно под каждый метод класса порта писать отдельный интерфейс? Т.е. порт - это по сути один метод? Или же можно делать порт с несколькими методами?
сложна. восхищаюсь людьми, которые способны держать в голове такие схемы зависимостей (без иронии). но у меня вот вопрос практического свойства: как организовано версионирование модулей? некоторые зависимости встречаются по несколько раз в 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
Отличное видео спасибо Вам большое!!! Тоже использую гексагональную архитектуру, но не разделяю по отдельным модулям порты ведь порты относятся к доменной модели? Может поправите если не так?
и все-таки какая то магия происходит с 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"
Теория рассказано емко и исчерпывающе, но реализация... Сложить каждый класс/интерфейс в свой пакет и обернуть каждый пакет своим модулем, а потом жонглировать модулями - не означает, что вы реализовали гексагональную архитектуру.
Ну, "жонглирование модулями" вообще не про гексагональную архитектуру) Я не совсем правильно выбрал название, сделав акцент именно на гексагональной архитектуре.
«Мне очень не нравятся аббревиатуры в названиях классов», «так называем класс Api, …. следующий класс Spi» 😂
Видео очень интересное, спасибо.
Да, я такой)
Вот интересно, одному мне показалось, что решение слишком переусложнено? По мне, схема, которая используется в большинстве спринг бутовых приложениях вида controller(listener, scheduled и т.д.) -> service -> repository (rest-template, kafka-template и т.д.) работает по тем же принципам, но не переусложнена деталями и допабстракциями. Пока ни разу не сталкивался с гексагоналкой, представленной именно в таком виде. Автору огромное спасибо за разъяснение принципов на практике.
Слоистую архитектуру люди научились варить)
А вот с гексагональной и ддд у большинства проблемы с пониманием + каждый по своему трактует
И там и там есть плюсы и минусы. Иногда классическая трехслойка в одном модуле будет предпочтительнее.
Титанический труд автора и бесценный контент. Как мне его не хватало пару лет назад. Спасибо за труд. По гексоганальной архитектуре мне так же понравилась книга Get Your Hands Dirty on Clean Architecture - там автор тож от теории сразу переходит к практике создания структуры приложения по гексагону, но в книге даже все попрорще, чем в этом видео. В этом видео прям от и до показана структура приложения. И как красиво и просто можно от монолита переходить к распределенным микросервисам. В случае если это действительно понадобилось, а не дань моде.
Снимай дальше!!! Отличный контент, я бы хотел увидеть ещё про написания правильной веб архитектуры в современном backend
Мне больше понравился доклад от DDDevotion по чистой архитектуре, но там не показывали процесс разделения на модули и т.п.
Я сейчас как раз пишу проект с гексагональной архитектурой, но отдельно на модули его я так и не решился разделить. Спасибо вам за это видео, сегодня постараюсь применить полученные знания)
Однозначно лучший джавист
Да ну нееее... Но спасибо)
Не показывайте это КРУДОделам, у них инфаркт случится
Не канал, а золотая кладезь знаний. Каждый видос вбирает в себя столько крутых и полезных знаний, что прям вау. Респект тебе, дружище, за такой контент
блин, какой же классный контент. Вот нигде такого не видел, если честно.
много спорных моментов, но в комментарии их не укажешь все
Было бы желание)
Про Spring ACL вообще только на этом канале впервые увидел)
Где же найти столько свободного времени чтоб это всё посмотреть ?))
Ну, яж нашёл как-то время это всё записать)
@@shurik_codes спасибо большое
Продолжайте
Мы обязательно все посмотрим )
Спасибо за классный контент.
Расскажи плиз что думаешь о Java modules ? Заметил что не используешь в этом тестовом проекте их. Что думаешь над возможностью скрыть часть пакетов с помощью Java modules ?
В целом удобный инструмент, хотя и не решающий всех задач при работе с пакетами, хочется чего-то большего. Вообще код этого проекта распределён таким образом, чтобы не возникло проблем при внедрении JPMS. Но это не продемонстрировано для экономии времени)
Верно ли я понял, что в реализации гексагональной архитектуры нужно под каждый метод класса порта писать отдельный интерфейс? Т.е. порт - это по сути один метод? Или же можно делать порт с несколькими методами?
Можно писать и несколько методов в одном порте, никто не запрещает. Я просто так трактую принцип разделения интерфейса.
уау, сочный контент, посмотрел в захлеб, по теме все делают по разному, увидел еще один вариант реализации))
Спасибище!
красиво!
Спасибо, Александр
👍
А кто может подсказать, что за плагинчик под идею с @simple 0%? Это про конгитивную сложность кода что-то?
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
Отличное видео спасибо Вам большое!!! Тоже использую гексагональную архитектуру, но не разделяю по отдельным модулям порты ведь порты относятся к доменной модели? Может поправите если не так?
Ну, домен делится на ограниченные контексты, которые реализуются в виде модулей, а каждый порт относится к тому или иному ограниченному контексту.
Александр, большое спасибо за видео. Получается, можно обойтись без доменной сущности, которая в ядре была?
В операциях чтения - да
Code Complexity - какой профит от этого плагина?
Оценка когнитивной сложности, ставил ради интереса
большое спасибо автору
и все-таки какая то магия происходит с 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"
Теория рассказано емко и исчерпывающе, но реализация... Сложить каждый класс/интерфейс в свой пакет и обернуть каждый пакет своим модулем, а потом жонглировать модулями - не означает, что вы реализовали гексагональную архитектуру.
Ну, "жонглирование модулями" вообще не про гексагональную архитектуру) Я не совсем правильно выбрал название, сделав акцент именно на гексагональной архитектуре.
Так расскажи