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

Проектирование и разработка архитектуры программного обеспечения является неотъемлемой и крайне важной составляющей процесса разработки. Гибкая и хорошо проработанная архитектура значительно упрощает процесс разработки как монолитных проектов, так и проектов с микросервисным подходом. А в идеальных условиях архитектура должна позволять получить из одной кодовой базы как модульный монолит, так и набор микросервисов.
На мой взгляд хорошей отправной точкой может стать гексагональная архитектура, которая является частной реализацией идей чистой архитектуры. В этом ролике я рассматриваю основные элементы гексагональной архитектуры, а так же демонстрирую её применение в процессе разработки простого сервиса, модульного монолита и набора микросервисов.
Репозиторий проекта: github.com/alex-kosarev/selma...
00:01:34 Гексагональная архитектура
00:08:32 Применение гексагональной архитектуры
00:30:01 Разделение модуля на библиотеки
00:41:25 Разработка модульного монолита
01:08:57 Разработка микросервисов
#java #hexagonal #softwarearchitecture #microservices #monolith #modularmonolith
Мой сайт: alexkosarev.name/
Паблик в VK: public218833461
Канал в Telegram: t.me/+TZCuO38vG3oqu_Jq
Стать доном: donut/shurik.codes
Донаты в Boosty: boosty.to/akosarev/purchase/1...
Донаты в Tinkoff: www.tinkoff.ru/cf/4PEOiVCZQuS

[@viktorperov9020]

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

[@serge3268]

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

[@shurik_codes]

Да, я такой)

[@senin24]

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

[@hackim2554]

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

[@user-ib8rv1vr4r]

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

[@a1dwow]

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

[@shurik_codes]

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

[@MrDartSaS]

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

[@psergeev77]

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

[@liliabekuzinaensosense8987]

Спасибище!

[@user-ib8rv1vr4r]

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

[@nickelakov6401]

🔥🔥🔥

[@user-ol2ii8dd5y]

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

[@inzagher]

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

[@walcermelodia]

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

[@lexxx1994]

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

[@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"

[@user-bn7vp9yz5e]

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

[@shurik_codes]

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

[@baxiskerimzade2690]

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

[@shurik_codes]

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

[@baxiskerimzade2690]

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

[@elsalvadore7063]

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

[@shurik_codes]

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

[@user-pq7tk7gd2h]

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

[@shurik_codes]

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

[@user-ib8rv1vr4r]

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

[@shurik_codes]

Code Complexity

[@resolution07]

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

[@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

[@dmaberlin]

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

[@shurik_codes]

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

[@user-cs9bs4gh3e]

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

[@shurik_codes]

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

[@mikhailkarpovdev]

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

[@shurik_codes]

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

[@user-eo2ti1qz6y]

Так расскажи