Гексагональная архитектура и микросервисы

[@senin24]

Титанический труд автора и бесценный контент. Как мне его не хватало пару лет назад. Спасибо за труд. По гексоганальной архитектуре мне так же понравилась книга Get Your Hands Dirty on Clean Architecture - там автор тож от теории сразу переходит к практике создания структуры приложения по гексагону, но в книге даже все попрорще, чем в этом видео. В этом видео прям от и до показана структура приложения. И как красиво и просто можно от монолита переходить к распределенным микросервисам. В случае если это действительно понадобилось, а не дань моде.

[@hackim2554]

Снимай дальше!!! Отличный контент, я бы хотел увидеть ещё про написания правильной веб архитектуры в современном backend

[@viktorperov9020]

Не канал, а золотая кладезь знаний. Каждый видос вбирает в себя столько крутых и полезных знаний, что прям вау. Респект тебе, дружище, за такой контент

[@БогданЗараник]

блин, какой же классный контент. Вот нигде такого не видел, если честно.

[@a1dwow]

много спорных моментов, но в комментарии их не укажешь все

[@shurik_codes]

Было бы желание)

[@serge3268]

«Мне очень не нравятся аббревиатуры в названиях классов», «так называем класс Api, …. следующий класс Spi» 😂 Видео очень интересное, спасибо.

[@shurik_codes]

Да, я такой)

[@psergeev77]

красиво! Спасибо, Александр

[@MrDartSaS]

уау, сочный контент, посмотрел в захлеб, по теме все делают по разному, увидел еще один вариант реализации))

[@liliabekuzinaensosense8987]

Спасибище!

[@Тимур-л1м]

Мне больше понравился доклад от DDDevotion по чистой архитектуре, но там не показывали процесс разделения на модули и т.п. Я сейчас как раз пишу проект с гексагональной архитектурой, но отдельно на модули его я так и не решился разделить. Спасибо вам за это видео, сегодня постараюсь применить полученные знания)

[@RatchetTV1515]

Однозначно лучший джавист

[@shurik_codes]

Да ну нееее... Но спасибо)

[@БогданЗараник]

Про Spring ACL вообще только на этом канале впервые увидел)

[@ANDREYQIWS]

Очень хочется к вам на индивидуальные занятия, если таковые будите вести.

[@inzagher]

Вот интересно, одному мне показалось, что решение слишком переусложнено? По мне, схема, которая используется в большинстве спринг бутовых приложениях вида controller(listener, scheduled и т.д.) -> service -> repository (rest-template, kafka-template и т.д.) работает по тем же принципам, но не переусложнена деталями и допабстракциями. Пока ни разу не сталкивался с гексагоналкой, представленной именно в таком виде. Автору огромное спасибо за разъяснение принципов на практике.

[@walcermelodia]

Слоистую архитектуру люди научились варить) А вот с гексагональной и ддд у большинства проблемы с пониманием + каждый по своему трактует

[@lexxx1994]

И там и там есть плюсы и минусы. Иногда классическая трехслойка в одном модуле будет предпочтительнее.

[@АлександрВолков-я6й]

Спасибо за классный контент. Расскажи плиз что думаешь о Java modules ? Заметил что не используешь в этом тестовом проекте их. Что думаешь над возможностью скрыть часть пакетов с помощью Java modules ?

[@shurik_codes]

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

[@e-researcher]

👍

[@androidandroid1893]

большое спасибо автору

[@androidandroid1893]

и все-таки какая то магия происходит с 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 .

[@androidandroid1893]

Не. Магии нет. Не было getter-ов в ProductCategoryPresentationV1

[@shurik_codes]

А так и должно быть, если метод возвращает "application/vnd.catalogue.product-category.v1+json", то единственное корректное значение заголовка Accept - именно "application/vnd.catalogue.product-category.v1+json"

[@munirsunchalyaev7484]

Подскажите, как реализовать с JPA. Где должны располагаться сущности и располагаться миграции?

[@baxiskerimzade2690]

Где же найти столько свободного времени чтоб это всё посмотреть ?))

[@shurik_codes]

Ну, яж нашёл как-то время это всё записать)

[@baxiskerimzade2690]

@@shurik_codes спасибо большое Продолжайте Мы обязательно все посмотрим )

[@nickelakov6401]

🔥🔥🔥

[@elsalvadore7063]

Отличное видео спасибо Вам большое!!! Тоже использую гексагональную архитектуру, но не разделяю по отдельным модулям порты ведь порты относятся к доменной модели? Может поправите если не так?

[@shurik_codes]

Ну, домен делится на ограниченные контексты, которые реализуются в виде модулей, а каждый порт относится к тому или иному ограниченному контексту.

[@ЕвгенийАлексеев-о9э]

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

[@shurik_codes]

В операциях чтения - да

[@sergeyshcherbakov3653]

сложна. восхищаюсь людьми, которые способны держать в голове такие схемы зависимостей (без иронии). но у меня вот вопрос практического свойства: как организовано версионирование модулей? некоторые зависимости встречаются по несколько раз в pom файлах модулей: customer-shared - 6 раз, catalogue-shared - 4 раза, customer-spi-catalogue - 4 раза, catalogue-api - 3 раза. И это у нас всего две бизнес-сущности - Customer и Catalogue, учебный пример! При изменении версии того или иного модуля, как мне кажется, довольно легко забыть внести соответстветствующие изменения во все остальные помники смежных модулей... Вы как с этим справляетесь? Если где-то ошибся или неправильно понял автора, заранее прошу прощения 😇

[@shurik_codes]

Обычно нет никаких проблем ручками обновлять версии, но вообще есть плагин versions, который позволяет упростить работу с версиями: www.mojohaus.org/versions/versions-maven-plugin/index.html

[@aleksey2793]

Верно ли я понял, что в реализации гексагональной архитектуры нужно под каждый метод класса порта писать отдельный интерфейс? Т.е. порт - это по сути один метод? Или же можно делать порт с несколькими методами?

[@shurik_codes]

Можно писать и несколько методов в одном порте, никто не запрещает. Я просто так трактую принцип разделения интерфейса.

[@resolution07]

Не показывайте это КРУДОделам, у них инфаркт случится

[@БогданЗараник]

А кто может подсказать, что за плагинчик под идею с @simple 0%? Это про конгитивную сложность кода что-то?

[@shurik_codes]

Code Complexity

[@dmaberlin]

Code Complexity - какой профит от этого плагина?

[@shurik_codes]

Оценка когнитивной сложности, ставил ради интереса

[@ИванПавлов-э6у]

Один глаз на нас, другой на Кавказ. А видос - класс)

[@shurik_codes]

Ох уже эти ваши шуточки про мои глаза...

[@mikhailkarpovdev]

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

[@shurik_codes]

Ну, "жонглирование модулями" вообще не про гексагональную архитектуру) Я не совсем правильно выбрал название, сделав акцент именно на гексагональной архитектуре.

[@Алексейм-с7б]

Так расскажи

[@К.ОТяра]

Архитектура ради архитектуры.. ну зачем так наворачивать все? Спрингбутовые микросервисы - простая как бревно вещь! Controiller - DTO+Mappers - Service - Repository/Entity Не нужно этих пакетов-модулей-spi-адфптеров.. jdbc еще вынесли куда-то отдельно.. о фак! столько лишних директорий, помников.. глаза болят!!