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

Рет қаралды 25,270

Жыл бұрын

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября, Санкт-Петербург
- -
В этом докладе вы увидите обзор архитектур Java-приложений и их проблемы.
Спикер даст краткий экскурс в эволюцию и виды архитектур и затронет следующие темы:
- Что такое Vertical Design.
- Что такое Horizontal Design и Three layered architecture.
- Почему появилась Hexagonal architecture, какую проблему она решает.
- Какие проблемы не решены этими архитектурами и куда можно двигаться?
- Почему это важно?
Будет много кода и примеров. Доклад будет интересен всем Java-разработчикам, независимо от грейда.
#horizontal_design #vertical_slice #hexagonal_architecture

Пікірлер: 57

@ul84222 Жыл бұрын

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

@dkrupsky 2 ай бұрын

Многие путают архитектуру и структуру модулей кода

@igorkhokhriakov2313 7 ай бұрын

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

@arusland42 Жыл бұрын

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

@Boyarsskiy 5 ай бұрын

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

@denissavast 4 ай бұрын

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

@antonvlasov9362 Жыл бұрын

Рустам, спасибо!

@alexeyskakun1088 9 ай бұрын

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

@user-lc8dw6qu7r 6 ай бұрын

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

@oleksandrvasylchenko316 Ай бұрын

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

@alexkluev561 9 ай бұрын

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

@sergeng-gd5ev 2 ай бұрын

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

@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 Итоги

@HZERR 6 ай бұрын

Спасибо за доклад :)

@AlexeyPirogov Жыл бұрын

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

@nopebutnope4215 Жыл бұрын

Для этих целей вполне можно использовать archunit вместо отдельных артефактов

@ivan42832 4 ай бұрын

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

@ivan42832 2 ай бұрын

@@faryellowstarНе совсем понял что значит не получится? Ну может в каком то паттерне и не получится, а это новый паттерен революционный) ну я шучу конечно, ничего революционного нет в нем. Щас попробую объяснить. Репозиторий слово не подходящее вероятно провайдер или хранилище ближе к сути. Представьте, у вас доменный объект, который собирается из нескольких источников, представьте например покупатель в магазине, часть данных тянется из бд магазина, а персональные данные тянуться из особого хранилища ПД по апи. Согласитесь удобно сделать CustomerProvider реализация которого возьмет данные из бд и сходит по апи, и собирет вам ваш доменный Customer и вернет. Удобнее же чем делать какой-то репозитории который возвращаю CustomerInfo, Апи клиент который возвращает CustomerPersData потом это еще все собирать. Ну в общем я использую пока кажется удобным такой подход.

@sergeynothing9324 Жыл бұрын

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

@iamdozerq 9 ай бұрын

Так он и рассматривает изолированно проблему архитектуры в таких погибающих проектах.

@Boyarsskiy 5 ай бұрын

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

@VitaliyMarenkov 4 ай бұрын

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

@hgfyos Жыл бұрын

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

@Eduard.Kardashov Жыл бұрын

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

@Eduard.Kardashov Жыл бұрын

Рустам еще не видел архитектурные решения в многомодульных Андроид приложениях, все свои шаблоны бы порвал

@stanislavzemlyakov5442 Жыл бұрын

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

@erikivanov1 11 ай бұрын

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

@alexanderchip988 Жыл бұрын

Согласен с докладчиком на 100%. Красиво реализованный MVC ничем не уступает всем новомодным луковицам и хексагонам. Но проблема мертвых проектов это не только архитектура и не Гад классес, супер менеджеры итд. Как правило это полное непонимание домена. И великий ДДД в этом не понимании мало чем помогает, а зачастую и добивает проекты. Есть мало образованные люди говорящие и пишущие без ошибок на русском, и есть такие же хорошо знающие свою Джаву программисты не способные погрузиться в область того, что они описывают. И тогда и функциональщина и ООП уже тоже путают, вредят и тормозят развитие проекта.

@igor8219 Жыл бұрын

Самая основная ценность ДДД - это как раз про понимание домена. Только акцент нужно делать больше на стратегические паттерны, о чем сам Вернон впоследствии и писал.

@VitaliyMarenkov 4 ай бұрын

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

@johnsnow2810 Жыл бұрын

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

@fannigurt 6 ай бұрын

kzbin.info/www/bejne/jme0lYqKepZ7ftk бизнес логика с протекшим фреймворком внутрь? Это как? Ты написал useCase какой то и вместо того чтобы его вызвать в ендпоинте и прокинуть ему все зависимости ты как то прокинул реквест от фреймворка? Или че произошло? Другой вопрос. А зачем?

@-dubok- 4 ай бұрын

Я думаю, докладчик путает горизонтальный и вертикальный дизайны. Горизонтальный - это как раз и есть микросервисы и разбиение на домены, потому что это горизонтальное масштабирование приложения, вширь, а вот трёхслойная архитектура - это вертикальный дизайн, что очевидно, так как слои идут вертикально, снизу-вверх и виден поток данных. Лично я, хотя и не имею опыта, но много времени потратил на изучение архитектуры, и склоняюсь, конечно же, к разбиению на домены. Если точнее, то идеальный вариант, по-моему, это EDA - event-driven architecture, где идёт разбиение на независимые сервисы, связанные через шину событий. Разрабатывать их удобно, но поток данных может быть не очевидным, как и в любой «вертикальной» архитектуре. Но, я думаю, он всегда понятен исходя из предназначения доменов и нарисованный схемы их взаимодействия, с чего и должно начинаться любое проектирование. Поэтому это немного глупо, пенять на то, что структура папок не показывает тебе поток данных. Она и не должна. Поток данных должен быть заранее показан на схеме. У любого приложения должна быть схема, графическая и должна быть документация. Не нужно пытаться понимать приложение по его коду. Понимать нужно по документации. И вот именно написание документации должно быть первичным при разработке любого приложения на любой архитектуре, потому что только так программистам становится понятно, а что же они все вместе делают и какую часть каждый должен пилить и как они потом связываются. Всё это должно быть обговорено заранее. И именно потому, что кодеры приходят и просто начинают писать как поэты во вдохновении, и возникают потом проблемы в неправильной работе и тяжести поддержки кода. А потому что код должен писаться не во вдохновении, а по строгой схеме. Потому что код - это не продукт творчества, а продукт инженерии, это реализация заранее продуманной схемы приложения.

@user-bg3sh3uw2c Жыл бұрын

очень много спорных моментов в докладе. Например: 1 Автор заявляет: "Современная хексогональнная архитектура от netflix очень похожа на слоеную". Хз, где там похожесть.... Хексагон это про изоляцию БЛ, все зависят от домена, а он, не от кого не зависит. И это как было с 2003 года постулатом, так и осталось. И на картинке нетфликса это прекрасно видно. Теперь же слоеная архитектура - верхний слой зависит от нижнего. Да и вообще, после таких выводах об общности хексагона и слоеной - много вопрос, а понимает ли автор о чем говорит? Перечислите хотя бы в чем преимущества хекагона и скажите, как этого добиться с помощью слоеной? 2 Автор заявляет: "Clean Archetecture слишком строг по поводу наличия фреймворков в БЛ(в том числе и спринга)" - опять очень громкие заявления, что без них писать нельзя. Посмотрите в сети куча проектов. Пихать спринг в БЛ - это убивание всей той хорошей задумки о том, что БЛ должна быть чистой. И я здесь даже не про либы, хотя их тоже по минимуму должно быть.... Я именно про DI, который должен собирать приложение из кусочков, а не являться частью БЛ. Вы же потом без спринга уже ничего не протестите?! Это же основной бенефит всех этих архитектур - облегчить тестирование кода!!! Почему вообще БЛ должна зависеть от спринга? Изменится мажорная версия - и всё, тю-тю, миграция на полгода? 3 Автор постоянно акцентирует про понятность структуры проекта - что весьма разумно. Однако, в отличие от хексагона, clean archetecture сдесь сделала шаг вперед, о котором ни слова - Screaming Architecture. Порты, контроллеры и др технические детали - это всё круто, но когда приложение само "кричит" что оно делает - это более сильный фактор. 4 Ни слова не сказано о простоте тестирования и возможности отложить принятия решений по выбору инфраструктуры на более поздние этапы. Возможно это результат того, что автор потом показал код, где БЛ всё так же как и раньше хранится в анемичных сервисах, с забиванием на SOLID, ООП, инкапсуляции и т.д. 5 Может если поменьше употреблять слово "папки", а использовать "пакеты", "модули" - то тогда вы более четче прочувствуете, что одна из основных решаемых проблем - это получение модульности и изменение направлений зависимости(изоляция БЛ)

@artem-wm7ou 9 ай бұрын

Плюсую! , очень рад что увидел тут ваш адекватный комментарий, под неадекватным докладом

@user-ve3hk5hg7k 9 ай бұрын

Поддержу пункты 2 и 4. Если отложить принятие решений, то вопрос "откуда приходят данные в модуль slack" даже поднимать бессмысленно. Сегодня могут из кафки, завтра из вебсокета. И при миграции даже в сам модуль slack не нужно будет заходить. Он вообще не должен знать откуда и куда пойдут данные

@anton-tkachenko Жыл бұрын

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

@ejasulan 5 ай бұрын

Антон, подумайте про какой то курс по ораторству, когда вы в 10 раз сказали ыыы было очень больно смотреть

@cbot4425 Жыл бұрын

А не работал ли он в Барс Груп? Чет имя знакомое, и если это он, то всё понятно. Там весь менеджмент был "такой" и лычка "тех дир" оттуда не стоит ровным счетом ничего.

@iamdozerq 9 ай бұрын

Хеххехе, а на свете один Барс или их много? Все приложения которые я когда либо встречал с названием Барс что-то-там нещадно меня ебали.

@hellocode_dev 7 ай бұрын

ааап...ээээ...с трудом выдержал первые минуты ну нельзя же так🤦‍♂️

@alexandr7686 11 ай бұрын

Гексагональная архитектура это про финтех и всякие интеграции через ESB, когда у вас есть свое коре ядро и куча разных провайдеров со своим апи, часто в формате xml\xsd, и вот как раз чтобы не писать кучу говнокода в ядре и нужны эти адаптеры, которые на себя берет ESB.

@Yurec10 Жыл бұрын

Антон Прохоров это, конечно, капец. Зачем начинать говорить с "аааа", это в уши слушателям срать. Не надо лишние звуки издавать, надо над речью поработать, все таки ведущий.

@Alex89muller 3 ай бұрын

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

@klim_neumann 3 ай бұрын

@@Alex89mullerВсе он по делу сказал.

@Alex89muller 3 ай бұрын

@@klim_neumann Так иди на другой канал. Тебя что тут держит-то. Не нравится не смотри.

@divergenny 2 ай бұрын

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

@mikhailbo8589 Жыл бұрын

проблема докладчика (и большинства разработчиков) в том что они не понимают разницу между "папка" и "пакет" (если говорить про Java). когда понимание придет, то сразу отпадет куча вопросов о том как правильно формировать структуру проекта

@vladimirtikaev5449 Жыл бұрын

Видимо я и сам не понимаю. Может есть какая-то статья или ресурс на эту тему?

@mikhailbo8589 Жыл бұрын

@@vladimirtikaev5449 к сожалению, статья не поможет.

@iamdozerq 9 ай бұрын

@@mikhailbo8589 Прежде чем что-то сделать человек всегда сначала это придумывает. Нельзя просто споткнуться и что бы из-за этого из небытия появились пакеты в джаве. Если нету манифеста к структуре файлов/папок/пакетов джавы, то эта структура не нужна и её не существует. Про манифест, изначальный "документ" определяющий назначение пакетов и папок в джаве он и справшивает. Если манифеста нет, то кто бы что не придумывал - это все есть просто так, без цели. Для обозначения такого состояния, когда что-то было придумано просто так есть слово "бред". Если нет статьи, то должна быть серия статей на КОНКРЕТНО ЭТУ ТЕМУ, если не серия статей, то книга, стандарт, что угодно. Мне бы самому найти откуда эти пакеты - разбивать файлы проекта по папкам для меня это невыносимая боль, а когда я в джаве увидел эти пакеты, я натурально взвыл. Если есть хоть что-то намекающее на их предназначение и что хотел ими сказать автор - я бы почитал.

@redofficiale 9 ай бұрын

Это очень странный аргумент. Как мне кажется из серии: "не папка, а директория". Пакет, по существу, это папка. То что он отражается в fq имени класса и может нести аннотации, тем самым давая дополнительный контекст классам в данном пакете/подпакетах - приятная фишка. Это не такой уровень изоляции как Модуль, чтобы настолько сильно триггериться на это.

@denisgolovin5594 Жыл бұрын

ааа иии ааа, ааа можно ааа ведущих ааа подбирать? ааа?

@user-gk2kn3ri7z Жыл бұрын

Антону очень неплохо бы отучиться от этого постоянного "ааа" между фразами. Довольно сильно напрягает

@rusmemes Жыл бұрын

доклад очень понравился, до некоторых идей сам додумался, но и нового для себя тоже узнал, буду применять на практике, особенна хороша идея с явным разделением потоков данных