Спасибо !

Отличный доклад, спасибо!

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

Интересный доклад

Сегодня проходил такую секцию в тинек и почти тоже самое нарисовал, а потом посмотрел этот доклад - Кирилл был бы счатстлив)

И с другой стороны - архитектурный собес того же твиттера с Вовой Ивановым и Артемом Зиннатуллиным

Да, молодец хорошо рассказал, на х1,75 посмотрел 🎉

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

Это не чистая архитектура. У вас бизнес логика зависит от слоя данных, а должно быть наоборот. То есть правило зависимостей уже не соблюдается. Говорите о solid, а сами не используете принцип dip. Много что из чистой архитектуры упущено: сущности, классы и интерфейсы ввода и вывода и т.п. В целом это больше напоминает старенькую луковую архитектуру, только без ключевого принципа инверсии зависимостей. Хорошая архитектура должна быть тестируемой, слабосвязной, не зависящей от деталей, таких как бд, фреймворк и т.п. Вот захотите вы сменить бд на nosql и что, будете бизнес логику менять? Аутентификация и уведомления это тоже все детали и говорить о них в контексте общей архитектуры не имеет смысла. Оптимизация туда же, да и вообще оптимизировать надо тогда, когда в этом есть нужда.

Разработчики: фу эти люди из других областей идут в ИТ только ради денях так же разработчики: больше всего просмотров у доклада на мобиусе - как пройти архитектурную часть собеса 🙃

Бред. Фича разрабатывается в рамках уже имеющейся архитектуры некоего проекта. То что нам показали - это заказчик с описанием некоторого функционала к приложению, которое надо написать с нуля. Большинство таких приложений будут иметь некую шаблонную архитектуру. Всегда нужен слой данных для похода в сеть или локальное хранилище, всегда есть внутренняя бизнес-логика, и есть экраны, он же UI. Всё остальное - частности. Если уж речь про архитектуру, то надо спрашивать - какие подходы знаете, например MVP, MVVM, VIPER. И уже в рамках этих концепций накидывать - как сходить в сеть и отобразить данные на экране. Как прикрутить пуши, как прикрутить веб-сокеты, как обеспечить отправку фоточек на сервер, как обеспечить сбор данных от пользователя на нескольких экранах с последующей отправкой на сервер и т.д.

Докладчик бездарь, описал совсем глупое решение по аутентфикациии, научился копировать слои и считает, что это он придумал супер архитектуру. Не верьте ему, прочтите сами книгу Clean Architecture.

Спасибо!