Рустам Ахметов — Архитектура приложения и ошибки проектирования

Ближайшая конференция — JPoint 2025, 3–4 апреля (Москва + трансляция).
— —
В этом докладе вы увидите обзор архитектур Java-приложений и их проблемы.

Спикер даст краткий экскурс в эволюцию и виды архитектур и затронет следующие темы:
— Что такое Vertical Design.
— Что такое Horizontal Design и Three layered architecture.
— Почему появилась Hexagonal architecture, какую проблему она решает.
— Какие проблемы не решены этими архитектурами и куда можно двигаться?
— Почему это важно?

Будет много кода и примеров. Доклад будет интересен всем Java-разработчикам, независимо от грейда.

#horizontal_design #vertical_slice #hexagonal_architecture

[sergeng-gdev]

Красавчик, хороший доклад. Многие тезисы прямо зашли)

[denissavast]

Благодарю! Отличная подача информации.

[Boyarsskiy]

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

[ul]

На мой взгляд в докладе затронута тема структуры приложения а не его архитектуры. Я увидел хороший пример с кубером - но согласны ли вы с утверждением, что предложенная в докладе структура была бы лучшим решением для сорцов кубера?

[ЯрославМизгирев-рр]

Хорошая аналитика. Рустам спасибо за ваш труд.

[igorkhokhriakov]

Классный доклад, спасибо! Мне понравилась концепция архитектуры Data Flow. В приципе пришёл к тому же с своих проектах, только называю Frontend-Middleware-Backend, и ещё думал про концепцию фрактальной архитектуры, когда эти сущности прослеживаются на всех уровнях, от клауда до веб компонента. В общем спасибо за доклад!

[polyackov_ot]

03:33 Вступление - Не все Арх всюду хороши
04:48 Horizontal Design
07:45 Vertical design
10:59 Hexagonal
13:30 Onion
15:33 Clean Architecture
16:47 Куда можно двигаться (Hexagonal from Netflx)
21:07 Как улучшить Horizontal Design чтобы остаться в тренде?
23:05 Проблемы и Успешные применения Архитектур с примерами кода
36:51 Репозиторий Кубера как пример сложной архитектуры
38:22 Итоги

[alexeyskakun]

Коллега, Спасибо за Ваш доклад, но:
1. На слайде ошибка: Eric Evans, не Rick
2. 3-х звенка и MVC разные вещи, а слайсинг вообще в стороне (контроллер, сервис, репозиторий).
3. Обращение из одного в сервис в другой скорее сильная связанность, т.е. coupling

[alexkluev]

В примере с раздлелением на in, out, model, config пакеты что предполагается класть в пакет model? Простые DTOшки или ещё и Entity?
В примере с Spring'ом репозиторий уже сам по себе интерфейс (без явной реализации, которую за тебя делает Spring). Его, выходит, можно сразу смело в ports положить рядом с ядром?

[ivan]

Классный доклад! Меня вот не так давно осенило что не нужно делить реализацию репозитория(или даже точнее хранилища) на типы Апи, БД, Мемори, Кеш и т.д. и это простое понимание снимает ряд проблем. Например при развитии проекта когда нам становится нужно получить, собрать сущность из двух и более источников, мы не думаем что же нам делать не вводим какие-то новые сущности, маперы и т.д. У нас просто есть хранилища сущностей, а как именно это все в реализации и ни как на структуру папок не влияет.

[arusland]

Крутой доклад. Буду использовать. Спасибо

[oleksandrvasylchenko]

Следует понимать, что архмтектура приложения описана, но не архитектура системы. Доклад отличный.

[Boyarsskiy]

Когда читал Чистую архитектуру, посетила точно такая же мысль: невозможно в реальных условиях очистить уровень бизнес-логики от фреймворка. Мне непонятно, как мы выкинем поддержку транзакций из сервисного уровня? Как Hibernate будет управлять версиями? Как мы будем делать ретраи? Как мы будем выбирать уровни изоляции? Мы теряем очень много и спускаемся на доисторический уровень, но с супер-пупер чистой архитектурой.

[aleksey]

Так у вас ваши же примеры организации папок в проектах названы в стиле "теплое", "мягкое", "плохое". Критерии из разных шкал абсолютно - old, bad, domain, function. И после этого вы рассуждаете о структуре папок проектов?) Подача материала также очень скомканная и непоследовательная. Хотя тема крайне интересная, причесать бы этот доклад, ссылку давал бы всем направо и налево.

[AlexeyPirogov]

Разбить "на папки" вначале это пол дела. Важно чтобы позже новичкам было сложно сделать что-то не правильно. Без отдельных артефактов тут не обойтись.

Все понимают что модель не должна знать о протоколах и большинстве фрейморков. Но это легко проглядеть на code review в import-ах, а вот изменения gradle/maven обычно аккуратно ревьювают. А еще можно добавить дополнительных правил.

Есть другие важные вопросы, модель клиента и сервера.

[sergeynothing]

Честно говоря меня смущает когда человека представляют тех диром (CTO) а он рассказывает как спасает проект закапываясь в структуру папок!
Кажется это немного не тот уровень и не про то?
Спасение проекта на уровне техдира - это команда 50 человек, с ними 50+ микросервисов, где-то полу-микросервисов, без четких стандартов разработки, без автоматизации интеграции, без явного разделения на домены, с пересекающимся функционалом, плохим CI/CD и конфликтами в командах!
Вот это я понимаю пришел CTO - спас проект! А ту типо залез в папочки и ... ну уровень middle/senior developer

[anton-tkachenko]

Рустам, ты золотой человек! Спасибо большое за прекрасный обзор и примерами

[johnsnow]

Рустам, спасибо за доклад.
Очень интересно и полезно.
И экскурс в эволюцию архитектур довольно интересный.

Вопрос к хейтерам: где можно ваши доклады посмотреть?

[hgfyos]

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

[stanislavzemlyakov]

Не думаю, что важность архитектуры диктуется сокращением времени онбординга. Время онбординга роляет, когда в команде дикая текучка. В таких командах хорошего поддерживаемого кода отродясь не видал.