Главная беда любой архитектуры - нежелание глубоко погружаться в бизнес процессы. Можно на простеньком MVC написать блестящий проект, в котором код и доменная модель прекрасно описывают что происходит, а можно поверхностно понять бизнес-процессы, и все это усложнить DDD, гексагональной архитектурой, сагами, оркестрациями, и т.д., и на выходе получить неподдерживаемый ад.
На мой взгляд в докладе затронута тема структуры приложения а не его архитектуры. Я увидел хороший пример с кубером - но согласны ли вы с утверждением, что предложенная в докладе структура была бы лучшим решением для сорцов кубера?
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 Итоги
Коллега, Спасибо за Ваш доклад, но: 1. На слайде ошибка: Eric Evans, не Rick 2. 3-х звенка и MVC разные вещи, а слайсинг вообще в стороне (контроллер, сервис, репозиторий). 3. Обращение из одного в сервис в другой скорее сильная связанность, т.е. coupling
В примере с раздлелением на in, out, model, config пакеты что предполагается класть в пакет model? Простые DTOшки или ещё и Entity? В примере с Spring'ом репозиторий уже сам по себе интерфейс (без явной реализации, которую за тебя делает Spring). Его, выходит, можно сразу смело в ports положить рядом с ядром?
Классный доклад, спасибо! Мне понравилась концепция архитектуры Data Flow. В приципе пришёл к тому же с своих проектах, только называю Frontend-Middleware-Backend, и ещё думал про концепцию фрактальной архитектуры, когда эти сущности прослеживаются на всех уровнях, от клауда до веб компонента. В общем спасибо за доклад!
Честно говоря меня смущает когда человека представляют тех диром (CTO) а он рассказывает как спасает проект закапываясь в структуру папок! Кажется это немного не тот уровень и не про то? Спасение проекта на уровне техдира - это команда 50 человек, с ними 50+ микросервисов, где-то полу-микросервисов, без четких стандартов разработки, без автоматизации интеграции, без явного разделения на домены, с пересекающимся функционалом, плохим CI/CD и конфликтами в командах! Вот это я понимаю пришел CTO - спас проект! А ту типо залез в папочки и ... ну уровень middle/senior developer
Классный доклад! Меня вот не так давно осенило что не нужно делить реализацию репозитория(или даже точнее хранилища) на типы Апи, БД, Мемори, Кеш и т.д. и это простое понимание снимает ряд проблем. Например при развитии проекта когда нам становится нужно получить, собрать сущность из двух и более источников, мы не думаем что же нам делать не вводим какие-то новые сущности, маперы и т.д. У нас просто есть хранилища сущностей, а как именно это все в реализации и ни как на структуру папок не влияет.
@@faryellowstarНе совсем понял что значит не получится? Ну может в каком то паттерне и не получится, а это новый паттерен революционный) ну я шучу конечно, ничего революционного нет в нем. Щас попробую объяснить. Репозиторий слово не подходящее вероятно провайдер или хранилище ближе к сути. Представьте, у вас доменный объект, который собирается из нескольких источников, представьте например покупатель в магазине, часть данных тянется из бд магазина, а персональные данные тянуться из особого хранилища ПД по апи. Согласитесь удобно сделать CustomerProvider реализация которого возьмет данные из бд и сходит по апи, и собирет вам ваш доменный Customer и вернет. Удобнее же чем делать какой-то репозитории который возвращаю CustomerInfo, Апи клиент который возвращает CustomerPersData потом это еще все собирать. Ну в общем я использую пока кажется удобным такой подход.
Разбить "на папки" вначале это пол дела. Важно чтобы позже новичкам было сложно сделать что-то не правильно. Без отдельных артефактов тут не обойтись. Все понимают что модель не должна знать о протоколах и большинстве фрейморков. Но это легко проглядеть на code review в import-ах, а вот изменения gradle/maven обычно аккуратно ревьювают. А еще можно добавить дополнительных правил. Есть другие важные вопросы, модель клиента и сервера.
Когда читал Чистую архитектуру, посетила точно такая же мысль: невозможно в реальных условиях очистить уровень бизнес-логики от фреймворка. Мне непонятно, как мы выкинем поддержку транзакций из сервисного уровня? Как Hibernate будет управлять версиями? Как мы будем делать ретраи? Как мы будем выбирать уровни изоляции? Мы теряем очень много и спускаемся на доисторический уровень, но с супер-пупер чистой архитектурой.
Все что необходимо в бизнес-слое но невозможно в нем реализовать объявляете в нем как интерфейсы. Те же репозитории, что они должны делать - это бизнес-логика, и вы описываете это как интерфейс. А вот то, как они это делают - это уже инфраструктура, реализацию пишите во внешнем слое, и она реализует (зависит от) этот интерфейс.
Так у вас ваши же примеры организации папок в проектах названы в стиле "теплое", "мягкое", "плохое". Критерии из разных шкал абсолютно - old, bad, domain, function. И после этого вы рассуждаете о структуре папок проектов?) Подача материала также очень скомканная и непоследовательная. Хотя тема крайне интересная, причесать бы этот доклад, ссылку давал бы всем направо и налево.
много оговорок и противоречий.. сначала говорит, что горизонтальная архитектура это разбиение по слоям на основе ххх (домен, например), потом, а вот гексогональная архитектура, а про ххх-то еще и не знали.. много терминологической путаницы из-за того, что подразумевалось в конкретной архитектуре, тогда когда она появилась и тем, как ее сейчас понимают
В принципе автор правильные вещи говорит, но не согласен только в том, что хорошая архитектура всё же нужна для большей гибкости кода, чтобы быстрее доставлять фичи и изменения, а не для быстрого онбординга (это следствие, а не причина)
очень много спорных моментов в докладе. Например: 1 Автор заявляет: "Современная хексогональнная архитектура от netflix очень похожа на слоеную". Хз, где там похожесть.... Хексагон это про изоляцию БЛ, все зависят от домена, а он, не от кого не зависит. И это как было с 2003 года постулатом, так и осталось. И на картинке нетфликса это прекрасно видно. Теперь же слоеная архитектура - верхний слой зависит от нижнего. Да и вообще, после таких выводах об общности хексагона и слоеной - много вопрос, а понимает ли автор о чем говорит? Перечислите хотя бы в чем преимущества хекагона и скажите, как этого добиться с помощью слоеной? 2 Автор заявляет: "Clean Archetecture слишком строг по поводу наличия фреймворков в БЛ(в том числе и спринга)" - опять очень громкие заявления, что без них писать нельзя. Посмотрите в сети куча проектов. Пихать спринг в БЛ - это убивание всей той хорошей задумки о том, что БЛ должна быть чистой. И я здесь даже не про либы, хотя их тоже по минимуму должно быть.... Я именно про DI, который должен собирать приложение из кусочков, а не являться частью БЛ. Вы же потом без спринга уже ничего не протестите?! Это же основной бенефит всех этих архитектур - облегчить тестирование кода!!! Почему вообще БЛ должна зависеть от спринга? Изменится мажорная версия - и всё, тю-тю, миграция на полгода? 3 Автор постоянно акцентирует про понятность структуры проекта - что весьма разумно. Однако, в отличие от хексагона, clean archetecture сдесь сделала шаг вперед, о котором ни слова - Screaming Architecture. Порты, контроллеры и др технические детали - это всё круто, но когда приложение само "кричит" что оно делает - это более сильный фактор. 4 Ни слова не сказано о простоте тестирования и возможности отложить принятия решений по выбору инфраструктуры на более поздние этапы. Возможно это результат того, что автор потом показал код, где БЛ всё так же как и раньше хранится в анемичных сервисах, с забиванием на SOLID, ООП, инкапсуляции и т.д. 5 Может если поменьше употреблять слово "папки", а использовать "пакеты", "модули" - то тогда вы более четче прочувствуете, что одна из основных решаемых проблем - это получение модульности и изменение направлений зависимости(изоляция БЛ)
Поддержу пункты 2 и 4. Если отложить принятие решений, то вопрос "откуда приходят данные в модуль slack" даже поднимать бессмысленно. Сегодня могут из кафки, завтра из вебсокета. И при миграции даже в сам модуль slack не нужно будет заходить. Он вообще не должен знать откуда и куда пойдут данные
Захейтили автора из за того, что он пытался высказать свои мысли а не как обезьяна копировать авторитетов. Думаю отличный доклад, а риторика со временем подтянется.
Я думаю, докладчик путает горизонтальный и вертикальный дизайны. Горизонтальный - это как раз и есть микросервисы и разбиение на домены, потому что это горизонтальное масштабирование приложения, вширь, а вот трёхслойная архитектура - это вертикальный дизайн, что очевидно, так как слои идут вертикально, снизу-вверх и виден поток данных. Лично я, хотя и не имею опыта, но много времени потратил на изучение архитектуры, и склоняюсь, конечно же, к разбиению на домены. Если точнее, то идеальный вариант, по-моему, это EDA - event-driven architecture, где идёт разбиение на независимые сервисы, связанные через шину событий. Разрабатывать их удобно, но поток данных может быть не очевидным, как и в любой «вертикальной» архитектуре. Но, я думаю, он всегда понятен исходя из предназначения доменов и нарисованный схемы их взаимодействия, с чего и должно начинаться любое проектирование. Поэтому это немного глупо, пенять на то, что структура папок не показывает тебе поток данных. Она и не должна. Поток данных должен быть заранее показан на схеме. У любого приложения должна быть схема, графическая и должна быть документация. Не нужно пытаться понимать приложение по его коду. Понимать нужно по документации. И вот именно написание документации должно быть первичным при разработке любого приложения на любой архитектуре, потому что только так программистам становится понятно, а что же они все вместе делают и какую часть каждый должен пилить и как они потом связываются. Всё это должно быть обговорено заранее. И именно потому, что кодеры приходят и просто начинают писать как поэты во вдохновении, и возникают потом проблемы в неправильной работе и тяжести поддержки кода. А потому что код должен писаться не во вдохновении, а по строгой схеме. Потому что код - это не продукт творчества, а продукт инженерии, это реализация заранее продуманной схемы приложения.
Как говорят, попытка комментировать код (читай, документировать) - это проблемы с выразительностью кода. Код и структура проекта должны быть максимально простыми и понятными, чтоб требовалось минимум документации.
@@KonstantinTarasov-q7q я про то, что надо писать доку вне кода, некую спецификацию, или, как в геймдизайне, диздок - дизайн-документ должен быть. Я её спекой называю для себя. И уже по ней пишешь код, в котором минимум комментариев - только там, где они нужны.
Не думаю, что важность архитектуры диктуется сокращением времени онбординга. Время онбординга роляет, когда в команде дикая текучка. В таких командах хорошего поддерживаемого кода отродясь не видал.
У Рустама очень хорошее предложение, однако, чтобы его правильно реализовать нужен очень хороший архитектор, так как Data Flow Architecture имеет склонность к трансформации в сложную событийно-ориентированную архитектуру при ошибках реализации. Но почему то он про это не говорит! Интересно, а почему? 🤔
ruclips.net/video/X6QdWTE1HHw/видео.html бизнес логика с протекшим фреймворком внутрь? Это как? Ты написал useCase какой то и вместо того чтобы его вызвать в ендпоинте и прокинуть ему все зависимости ты как то прокинул реквест от фреймворка? Или че произошло? Другой вопрос. А зачем?
Согласен с докладчиком на 100%. Красиво реализованный MVC ничем не уступает всем новомодным луковицам и хексагонам. Но проблема мертвых проектов это не только архитектура и не Гад классес, супер менеджеры итд. Как правило это полное непонимание домена. И великий ДДД в этом не понимании мало чем помогает, а зачастую и добивает проекты. Есть мало образованные люди говорящие и пишущие без ошибок на русском, и есть такие же хорошо знающие свою Джаву программисты не способные погрузиться в область того, что они описывают. И тогда и функциональщина и ООП уже тоже путают, вредят и тормозят развитие проекта.
Самая основная ценность ДДД - это как раз про понимание домена. Только акцент нужно делать больше на стратегические паттерны, о чем сам Вернон впоследствии и писал.
DDD и чистая архитектура как раз позволяют программистам не слишком разбираясь в бизнес-процессах создавать бизнес-ядро приложения совместно с экспертами от бизнеса. А уже имея спроектированное и выверенное ядро дальше можно обвешивать его какими-то техническими вещами - сохранением данных в базу, API, GUI, и т.п.
Рустам, спасибо за доклад. Очень интересно и полезно. И экскурс в эволюцию архитектур довольно интересный. Вопрос к хейтерам: где можно ваши доклады посмотреть?
А не работал ли он в Барс Груп? Чет имя знакомое, и если это он, то всё понятно. Там весь менеджмент был "такой" и лычка "тех дир" оттуда не стоит ровным счетом ничего.
Гексагональная архитектура это про финтех и всякие интеграции через ESB, когда у вас есть свое коре ядро и куча разных провайдеров со своим апи, часто в формате xml\xsd, и вот как раз чтобы не писать кучу говнокода в ядре и нужны эти адаптеры, которые на себя берет ESB.
Антон Прохоров это, конечно, капец. Зачем начинать говорить с "аааа", это в уши слушателям срать. Не надо лишние звуки издавать, надо над речью поработать, все таки ведущий.
Дружище, по моему лишние звуки здесь издаешь только ты. Автор приготовил годный материал, выложил его, для того чтобы ты мог чему-то научиться. Ты же как пуп земли себя ведешь. Не нравится не смотри в чем проблема?
Есть разная анатомия мозга, кто то говорун хороший, а кто то круто проектирует системы. Что бы два таких таланта совмещались, это редко бывает. Нефиг к человеку придераться, сами попробуйте на большую аудиторию выступать без ошибок и давать при этом правильную и полезную информацию.
проблема докладчика (и большинства разработчиков) в том что они не понимают разницу между "папка" и "пакет" (если говорить про Java). когда понимание придет, то сразу отпадет куча вопросов о том как правильно формировать структуру проекта
@@mikhailbo8589 Прежде чем что-то сделать человек всегда сначала это придумывает. Нельзя просто споткнуться и что бы из-за этого из небытия появились пакеты в джаве. Если нету манифеста к структуре файлов/папок/пакетов джавы, то эта структура не нужна и её не существует. Про манифест, изначальный "документ" определяющий назначение пакетов и папок в джаве он и справшивает. Если манифеста нет, то кто бы что не придумывал - это все есть просто так, без цели. Для обозначения такого состояния, когда что-то было придумано просто так есть слово "бред". Если нет статьи, то должна быть серия статей на КОНКРЕТНО ЭТУ ТЕМУ, если не серия статей, то книга, стандарт, что угодно. Мне бы самому найти откуда эти пакеты - разбивать файлы проекта по папкам для меня это невыносимая боль, а когда я в джаве увидел эти пакеты, я натурально взвыл. Если есть хоть что-то намекающее на их предназначение и что хотел ими сказать автор - я бы почитал.
Это очень странный аргумент. Как мне кажется из серии: "не папка, а директория". Пакет, по существу, это папка. То что он отражается в fq имени класса и может нести аннотации, тем самым давая дополнительный контекст классам в данном пакете/подпакетах - приятная фишка. Это не такой уровень изоляции как Модуль, чтобы настолько сильно триггериться на это.
доклад очень понравился, до некоторых идей сам додумался, но и нового для себя тоже узнал, буду применять на практике, особенна хороша идея с явным разделением потоков данных
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Главная беда любой архитектуры - нежелание глубоко погружаться в бизнес процессы. Можно на простеньком MVC написать блестящий проект, в котором код и доменная модель прекрасно описывают что происходит, а можно поверхностно понять бизнес-процессы, и все это усложнить DDD, гексагональной архитектурой, сагами, оркестрациями, и т.д., и на выходе получить неподдерживаемый ад.
На мой взгляд в докладе затронута тема структуры приложения а не его архитектуры. Я увидел хороший пример с кубером - но согласны ли вы с утверждением, что предложенная в докладе структура была бы лучшим решением для сорцов кубера?
Многие путают архитектуру и структуру модулей кода
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 Итоги
Благодарю! Отличная подача информации.
Красавчик, хороший доклад. Многие тезисы прямо зашли)
Хорошая аналитика. Рустам спасибо за ваш труд.
Коллега, Спасибо за Ваш доклад, но:
1. На слайде ошибка: Eric Evans, не Rick
2. 3-х звенка и MVC разные вещи, а слайсинг вообще в стороне (контроллер, сервис, репозиторий).
3. Обращение из одного в сервис в другой скорее сильная связанность, т.е. coupling
В примере с раздлелением на in, out, model, config пакеты что предполагается класть в пакет model? Простые DTOшки или ещё и Entity?
В примере с Spring'ом репозиторий уже сам по себе интерфейс (без явной реализации, которую за тебя делает Spring). Его, выходит, можно сразу смело в ports положить рядом с ядром?
Классный доклад, спасибо! Мне понравилась концепция архитектуры Data Flow. В приципе пришёл к тому же с своих проектах, только называю Frontend-Middleware-Backend, и ещё думал про концепцию фрактальной архитектуры, когда эти сущности прослеживаются на всех уровнях, от клауда до веб компонента. В общем спасибо за доклад!
Честно говоря меня смущает когда человека представляют тех диром (CTO) а он рассказывает как спасает проект закапываясь в структуру папок!
Кажется это немного не тот уровень и не про то?
Спасение проекта на уровне техдира - это команда 50 человек, с ними 50+ микросервисов, где-то полу-микросервисов, без четких стандартов разработки, без автоматизации интеграции, без явного разделения на домены, с пересекающимся функционалом, плохим CI/CD и конфликтами в командах!
Вот это я понимаю пришел CTO - спас проект! А ту типо залез в папочки и ... ну уровень middle/senior developer
Так он и рассматривает изолированно проблему архитектуры в таких погибающих проектах.
Не понимать важности темы, о которой идет речь и есть уровень middle/junior.
Классный доклад! Меня вот не так давно осенило что не нужно делить реализацию репозитория(или даже точнее хранилища) на типы Апи, БД, Мемори, Кеш и т.д. и это простое понимание снимает ряд проблем. Например при развитии проекта когда нам становится нужно получить, собрать сущность из двух и более источников, мы не думаем что же нам делать не вводим какие-то новые сущности, маперы и т.д. У нас просто есть хранилища сущностей, а как именно это все в реализации и ни как на структуру папок не влияет.
@@faryellowstarНе совсем понял что значит не получится? Ну может в каком то паттерне и не получится, а это новый паттерен революционный) ну я шучу конечно, ничего революционного нет в нем.
Щас попробую объяснить. Репозиторий слово не подходящее вероятно провайдер или хранилище ближе к сути. Представьте, у вас доменный объект, который собирается из нескольких источников, представьте например покупатель в магазине, часть данных тянется из бд магазина, а персональные данные тянуться из особого хранилища ПД по апи. Согласитесь удобно сделать CustomerProvider реализация которого возьмет данные из бд и сходит по апи, и собирет вам ваш доменный Customer и вернет. Удобнее же чем делать какой-то репозитории который возвращаю CustomerInfo, Апи клиент который возвращает CustomerPersData потом это еще все собирать. Ну в общем я использую пока кажется удобным такой подход.
Следует понимать, что архмтектура приложения описана, но не архитектура системы. Доклад отличный.
Спасибо за доклад :)
Разбить "на папки" вначале это пол дела. Важно чтобы позже новичкам было сложно сделать что-то не правильно. Без отдельных артефактов тут не обойтись.
Все понимают что модель не должна знать о протоколах и большинстве фрейморков. Но это легко проглядеть на code review в import-ах, а вот изменения gradle/maven обычно аккуратно ревьювают. А еще можно добавить дополнительных правил.
Есть другие важные вопросы, модель клиента и сервера.
Для этих целей вполне можно использовать archunit вместо отдельных артефактов
Что такое Archunit?
Когда читал Чистую архитектуру, посетила точно такая же мысль: невозможно в реальных условиях очистить уровень бизнес-логики от фреймворка. Мне непонятно, как мы выкинем поддержку транзакций из сервисного уровня? Как Hibernate будет управлять версиями? Как мы будем делать ретраи? Как мы будем выбирать уровни изоляции? Мы теряем очень много и спускаемся на доисторический уровень, но с супер-пупер чистой архитектурой.
Все что необходимо в бизнес-слое но невозможно в нем реализовать объявляете в нем как интерфейсы. Те же репозитории, что они должны делать - это бизнес-логика, и вы описываете это как интерфейс. А вот то, как они это делают - это уже инфраструктура, реализацию пишите во внешнем слое, и она реализует (зависит от) этот интерфейс.
Так у вас ваши же примеры организации папок в проектах названы в стиле "теплое", "мягкое", "плохое". Критерии из разных шкал абсолютно - old, bad, domain, function. И после этого вы рассуждаете о структуре папок проектов?) Подача материала также очень скомканная и непоследовательная. Хотя тема крайне интересная, причесать бы этот доклад, ссылку давал бы всем направо и налево.
Большое спасибо!
Крутой доклад. Буду использовать. Спасибо
Рустам, спасибо!
много оговорок и противоречий..
сначала говорит, что горизонтальная архитектура это разбиение по слоям на основе ххх (домен, например), потом, а вот гексогональная архитектура, а про ххх-то еще и не знали.. много терминологической путаницы из-за того, что подразумевалось в конкретной архитектуре, тогда когда она появилась и тем, как ее сейчас понимают
В принципе автор правильные вещи говорит, но не согласен только в том, что хорошая архитектура всё же нужна для большей гибкости кода, чтобы быстрее доставлять фичи и изменения, а не для быстрого онбординга (это следствие, а не причина)
очень много спорных моментов в докладе.
Например:
1 Автор заявляет: "Современная хексогональнная архитектура от netflix очень похожа на слоеную". Хз, где там похожесть.... Хексагон это про изоляцию БЛ, все зависят от домена, а он, не от кого не зависит. И это как было с 2003 года постулатом, так и осталось. И на картинке нетфликса это прекрасно видно. Теперь же слоеная архитектура - верхний слой зависит от нижнего. Да и вообще, после таких выводах об общности хексагона и слоеной - много вопрос, а понимает ли автор о чем говорит? Перечислите хотя бы в чем преимущества хекагона и скажите, как этого добиться с помощью слоеной?
2 Автор заявляет: "Clean Archetecture слишком строг по поводу наличия фреймворков в БЛ(в том числе и спринга)" - опять очень громкие заявления, что без них писать нельзя. Посмотрите в сети куча проектов. Пихать спринг в БЛ - это убивание всей той хорошей задумки о том, что БЛ должна быть чистой. И я здесь даже не про либы, хотя их тоже по минимуму должно быть.... Я именно про DI, который должен собирать приложение из кусочков, а не являться частью БЛ. Вы же потом без спринга уже ничего не протестите?! Это же основной бенефит всех этих архитектур - облегчить тестирование кода!!! Почему вообще БЛ должна зависеть от спринга? Изменится мажорная версия - и всё, тю-тю, миграция на полгода?
3 Автор постоянно акцентирует про понятность структуры проекта - что весьма разумно. Однако, в отличие от хексагона, clean archetecture сдесь сделала шаг вперед, о котором ни слова - Screaming Architecture. Порты, контроллеры и др технические детали - это всё круто, но когда приложение само "кричит" что оно делает - это более сильный фактор.
4 Ни слова не сказано о простоте тестирования и возможности отложить принятия решений по выбору инфраструктуры на более поздние этапы. Возможно это результат того, что автор потом показал код, где БЛ всё так же как и раньше хранится в анемичных сервисах, с забиванием на SOLID, ООП, инкапсуляции и т.д.
5 Может если поменьше употреблять слово "папки", а использовать "пакеты", "модули" - то тогда вы более четче прочувствуете, что одна из основных решаемых проблем - это получение модульности и изменение направлений зависимости(изоляция БЛ)
Плюсую! , очень рад что увидел тут ваш адекватный комментарий, под неадекватным докладом
Поддержу пункты 2 и 4. Если отложить принятие решений, то вопрос "откуда приходят данные в модуль slack" даже поднимать бессмысленно. Сегодня могут из кафки, завтра из вебсокета. И при миграции даже в сам модуль slack не нужно будет заходить. Он вообще не должен знать откуда и куда пойдут данные
Что такое изоляция БЛ? Можно это на русский язык перевести и расшифровать?
@@ОлегИванов-я2ж5и БЛ - бизнес логика.
@@ОлегИванов-я2ж5и я думаю изоляция Бизнес Логики
Захейтили автора из за того, что он пытался высказать свои мысли а не как обезьяна копировать авторитетов. Думаю отличный доклад, а риторика со временем подтянется.
Я думаю, докладчик путает горизонтальный и вертикальный дизайны. Горизонтальный - это как раз и есть микросервисы и разбиение на домены, потому что это горизонтальное масштабирование приложения, вширь, а вот трёхслойная архитектура - это вертикальный дизайн, что очевидно, так как слои идут вертикально, снизу-вверх и виден поток данных.
Лично я, хотя и не имею опыта, но много времени потратил на изучение архитектуры, и склоняюсь, конечно же, к разбиению на домены. Если точнее, то идеальный вариант, по-моему, это EDA - event-driven architecture, где идёт разбиение на независимые сервисы, связанные через шину событий. Разрабатывать их удобно, но поток данных может быть не очевидным, как и в любой «вертикальной» архитектуре. Но, я думаю, он всегда понятен исходя из предназначения доменов и нарисованный схемы их взаимодействия, с чего и должно начинаться любое проектирование.
Поэтому это немного глупо, пенять на то, что структура папок не показывает тебе поток данных. Она и не должна. Поток данных должен быть заранее показан на схеме. У любого приложения должна быть схема, графическая и должна быть документация. Не нужно пытаться понимать приложение по его коду. Понимать нужно по документации. И вот именно написание документации должно быть первичным при разработке любого приложения на любой архитектуре, потому что только так программистам становится понятно, а что же они все вместе делают и какую часть каждый должен пилить и как они потом связываются. Всё это должно быть обговорено заранее. И именно потому, что кодеры приходят и просто начинают писать как поэты во вдохновении, и возникают потом проблемы в неправильной работе и тяжести поддержки кода. А потому что код должен писаться не во вдохновении, а по строгой схеме. Потому что код - это не продукт творчества, а продукт инженерии, это реализация заранее продуманной схемы приложения.
Как говорят, попытка комментировать код (читай, документировать) - это проблемы с выразительностью кода. Код и структура проекта должны быть максимально простыми и понятными, чтоб требовалось минимум документации.
@@KonstantinTarasov-q7q я про то, что надо писать доку вне кода, некую спецификацию, или, как в геймдизайне, диздок - дизайн-документ должен быть. Я её спекой называю для себя. И уже по ней пишешь код, в котором минимум комментариев - только там, где они нужны.
Не думаю, что важность архитектуры диктуется сокращением времени онбординга. Время онбординга роляет, когда в команде дикая текучка. В таких командах хорошего поддерживаемого кода отродясь не видал.
У Рустама очень хорошее предложение, однако, чтобы его правильно реализовать нужен очень хороший архитектор, так как Data Flow Architecture имеет склонность к трансформации в сложную событийно-ориентированную архитектуру при ошибках реализации. Но почему то он про это не говорит! Интересно, а почему? 🤔
Рустам еще не видел архитектурные решения в многомодульных Андроид приложениях, все свои шаблоны бы порвал
ruclips.net/video/X6QdWTE1HHw/видео.html бизнес логика с протекшим фреймворком внутрь? Это как? Ты написал useCase какой то и вместо того чтобы его вызвать в ендпоинте и прокинуть ему все зависимости ты как то прокинул реквест от фреймворка? Или че произошло? Другой вопрос. А зачем?
Рустам, ты золотой человек! Спасибо большое за прекрасный обзор и примерами
Согласен с докладчиком на 100%. Красиво реализованный MVC ничем не уступает всем новомодным луковицам и хексагонам. Но проблема мертвых проектов это не только архитектура и не Гад классес, супер менеджеры итд. Как правило это полное непонимание домена. И великий ДДД в этом не понимании мало чем помогает, а зачастую и добивает проекты. Есть мало образованные люди говорящие и пишущие без ошибок на русском, и есть такие же хорошо знающие свою Джаву программисты не способные погрузиться в область того, что они описывают. И тогда и функциональщина и ООП уже тоже путают, вредят и тормозят развитие проекта.
Самая основная ценность ДДД - это как раз про понимание домена. Только акцент нужно делать больше на стратегические паттерны, о чем сам Вернон впоследствии и писал.
DDD и чистая архитектура как раз позволяют программистам не слишком разбираясь в бизнес-процессах создавать бизнес-ядро приложения совместно с экспертами от бизнеса. А уже имея спроектированное и выверенное ядро дальше можно обвешивать его какими-то техническими вещами - сохранением данных в базу, API, GUI, и т.п.
Как мвс конфликтует с гексагоналкой и луковкой?
Достаточно скомкано. Единой картины от доклада нет =(
ааа иии ааа, ааа можно ааа ведущих ааа подбирать? ааа?
Рустам, спасибо за доклад.
Очень интересно и полезно.
И экскурс в эволюцию архитектур довольно интересный.
Вопрос к хейтерам: где можно ваши доклады посмотреть?
Антон, подумайте про какой то курс по ораторству, когда вы в 10 раз сказали ыыы было очень больно смотреть
ааап...ээээ...с трудом выдержал первые минуты ну нельзя же так🤦♂️
А не работал ли он в Барс Груп? Чет имя знакомое, и если это он, то всё понятно. Там весь менеджмент был "такой" и лычка "тех дир" оттуда не стоит ровным счетом ничего.
Хеххехе, а на свете один Барс или их много? Все приложения которые я когда либо встречал с названием Барс что-то-там нещадно меня ебали.
Гексагональная архитектура это про финтех и всякие интеграции через ESB, когда у вас есть свое коре ядро и куча разных провайдеров со своим апи, часто в формате xml\xsd, и вот как раз чтобы не писать кучу говнокода в ядре и нужны эти адаптеры, которые на себя берет ESB.
Антон Прохоров это, конечно, капец. Зачем начинать говорить с "аааа", это в уши слушателям срать. Не надо лишние звуки издавать, надо над речью поработать, все таки ведущий.
Дружище, по моему лишние звуки здесь издаешь только ты. Автор приготовил годный материал, выложил его, для того чтобы ты мог чему-то научиться. Ты же как пуп земли себя ведешь. Не нравится не смотри в чем проблема?
@@Alex89mullerВсе он по делу сказал.
@@klim_neumann Так иди на другой канал. Тебя что тут держит-то. Не нравится не смотри.
Есть разная анатомия мозга, кто то говорун хороший, а кто то круто проектирует системы. Что бы два таких таланта совмещались, это редко бывает. Нефиг к человеку придераться, сами попробуйте на большую аудиторию выступать без ошибок и давать при этом правильную и полезную информацию.
@@Alex89muller так парень прав.
Его очень больно слушать
Эээээ Ааааа эээаааа плохая речь !
Антон Прохоров!!!! АААА ЭЭЭЭЭ нельзя же так разговаривать!!!!! Я не смог тебя слушать вообще.
Антону очень неплохо бы отучиться от этого постоянного "ааа" между фразами. Довольно сильно напрягает
Мягко говоря
проблема докладчика (и большинства разработчиков) в том что они не понимают разницу между "папка" и "пакет" (если говорить про Java). когда понимание придет, то сразу отпадет куча вопросов о том как правильно формировать структуру проекта
Видимо я и сам не понимаю. Может есть какая-то статья или ресурс на эту тему?
@@vladimirtikaev5449 к сожалению, статья не поможет.
@@mikhailbo8589 Прежде чем что-то сделать человек всегда сначала это придумывает. Нельзя просто споткнуться и что бы из-за этого из небытия появились пакеты в джаве. Если нету манифеста к структуре файлов/папок/пакетов джавы, то эта структура не нужна и её не существует. Про манифест, изначальный "документ" определяющий назначение пакетов и папок в джаве он и справшивает. Если манифеста нет, то кто бы что не придумывал - это все есть просто так, без цели. Для обозначения такого состояния, когда что-то было придумано просто так есть слово "бред".
Если нет статьи, то должна быть серия статей на КОНКРЕТНО ЭТУ ТЕМУ, если не серия статей, то книга, стандарт, что угодно. Мне бы самому найти откуда эти пакеты - разбивать файлы проекта по папкам для меня это невыносимая боль, а когда я в джаве увидел эти пакеты, я натурально взвыл. Если есть хоть что-то намекающее на их предназначение и что хотел ими сказать автор - я бы почитал.
Это очень странный аргумент. Как мне кажется из серии: "не папка, а директория".
Пакет, по существу, это папка. То что он отражается в fq имени класса и может нести аннотации, тем самым давая дополнительный контекст классам в данном пакете/подпакетах - приятная фишка. Это не такой уровень изоляции как Модуль, чтобы настолько сильно триггериться на это.
доклад очень понравился, до некоторых идей сам додумался, но и нового для себя тоже узнал, буду применять на практике, особенна хороша идея с явным разделением потоков данных