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

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

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

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

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

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

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

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

очень много спорных моментов в докладе.

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

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

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

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

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

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

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

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

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

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

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

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

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

Блять, layer не равно tier, вы че архитектора ?

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

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

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

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

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

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

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

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

Антон Прохоров!!!! АААА ЭЭЭЭЭ нельзя же так разговаривать!!!!! Я не смог тебя слушать вообще.

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

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

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

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

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

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

Я думаю, докладчик путает горизонтальный и вертикальный дизайны. Горизонтальный — это как раз и есть микросервисы и разбиение на домены, потому что это горизонтальное масштабирование приложения, вширь, а вот трёхслойная архитектура — это вертикальный дизайн, что очевидно, так как слои идут вертикально, снизу-вверх и виден поток данных.

Лично я, хотя и не имею опыта, но много времени потратил на изучение архитектуры, и склоняюсь, конечно же, к разбиению на домены. Если точнее, то идеальный вариант, по-моему, это EDA — event-driven architecture, где идёт разбиение на независимые сервисы, связанные через шину событий. Разрабатывать их удобно, но поток данных может быть не очевидным, как и в любой «вертикальной» архитектуре. Но, я думаю, он всегда понятен исходя из предназначения доменов и нарисованный схемы их взаимодействия, с чего и должно начинаться любое проектирование.

Поэтому это немного глупо, пенять на то, что структура папок не показывает тебе поток данных. Она и не должна. Поток данных должен быть заранее показан на схеме. У любого приложения должна быть схема, графическая и должна быть документация. Не нужно пытаться понимать приложение по его коду. Понимать нужно по документации. И вот именно написание документации должно быть первичным при разработке любого приложения на любой архитектуре, потому что только так программистам становится понятно, а что же они все вместе делают и какую часть каждый должен пилить и как они потом связываются. Всё это должно быть обговорено заранее. И именно потому, что кодеры приходят и просто начинают писать как поэты во вдохновении, и возникают потом проблемы в неправильной работе и тяжести поддержки кода. А потому что код должен писаться не во вдохновении, а по строгой схеме. Потому что код — это не продукт творчества, а продукт инженерии, это реализация заранее продуманной схемы приложения.

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

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

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

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

Большое спасибо!

Эээээ Ааааа эээаааа плохая речь !

У Рустама очень хорошее предложение, однако, чтобы его правильно реализовать нужен очень хороший архитектор, так как Data Flow Architecture имеет склонность к трансформации в сложную событийно-ориентированную архитектуру при ошибках реализации. Но почему то он про это не говорит! Интересно, а почему? 🤔

Достаточно скомкано. Единой картины от доклада нет =(

Rick owens