Best Practice по проектированию архитектуры приложений.
4 ак. часа в нед.
Ср 20:00, Пт 20:00
Что даст вам этот курс
Программа нацелена на формирование целостного понимания современных архитектурных практик проектирования. Охватывает основные архитектурные паттерны, тактики работы с атрибутами качества и технологические домены, необходимые архитектору в 2023 году.
Курс будет интересен архитекторам, разработчикам, тим лидам, которые хотят изучить более продвинутые техники построения архитектуры.
Длительность курса — 4 месяца.
Программа курса включает в себя:
- Разбор самых важных тактик по работе с различными атрибутами качества архитектуры: доступнось, отказоустойчивость, безопасность, и т.д.;
- Разбор основных паттернов и стилей архитектуры, их плюсов, минусов и подводных камней;
- Обзор основных технологических доменов и специфичных для них архитектур: бекенд, BigData, мобильная разработка, фронтенд, хранилища данных.
ГЕНЕРЮ ПЛАНИРОВКИ В НЕЙРОСЕТЯХ | АРХИТЕКТУРА В ИИ
Преподаватели
Станислав Щетинников
Директор по развитию в Сбербанке
Сергей Кривонос
Руководитель по развитию платформы API Management в АО ДОМ.РФ
Анатолий Бурнашев
Эксперт Центра практик обеспечения надёжности в MTS.Digital / Руководитель курса DevRel
Дамир Рысаев
Team Lead, AnyClass
Евгений Павлов
Евгений Непомнящий
Разработчик в IT-Sense
Программирует больше 15 лет. Архитектурой систем занимается уже больше 8 лет.
До этого несколько лет работал руководителем разработки в myTarget и Домклик. Любит Data Science, python, golang, DDD и микросервисную архитектуру.
Преподаватель
Программирую более 16 лет.
Последние 8 лет занимаюсь архитектурой систем, вопросами интеграций систем в Банковской сфере на платформах
класса ESB (IBM Integration Bus, IBM WebSphere MQ), а также проектированием архитектуры
решения и внедрением платформ API Management (WSO2 / Gravitee)
Преподаватель
20+ лет на проектах заказной разработки в ИТ.
Десятки успешных проектов, в том числе — по государственным контрактам.
Опыт разработки и внедрения ERP-систем, open-source решений, поддержка высоконагруженных приложений.
Преподаватель курсов по Linux, Kuber, MLOps, DataOps, SolutionArchitect, IaC, SRE, а так же наставник курса HighLoad
Преподаватель
Программированием увлёкся ещё в школе (2009 году). В 2015 году получил степень бакалавра по направлению «программная инженерия» в РГСУ. Коммерческой разработкой начал заниматься в студенческие годы, в 2012 году.
C 2019 работает наставником по направлению javascript в HTMLAcademy, основная работа — тим-лид / старший фронтенд разработчик в компании AnyClass.
Любит учиться и помогать учиться другим. Во время прокрастинации начинает проходить курсы.
Проектирование архитектуры систем 1С // Демо-занятие курса «Архитектор 1С»
Преподаватель
Программирую на разных языках и настраиваю Linux сервера с 2010 года.
Более трёх лет назад я перебрался в Израиль и работал на позициях DevOps TeamLead и Cloud Solution Architect.
Являюсь экспертом в области Kubernetes, Observability и Scrum.
Сейчас работаю над инфраструктурой в Yandex Self-Driving Group
Преподаватель
C++ и Java разработчик.
В отрасли с 2006 года. Долгое время занимался разработкой под микроконтроллеры на С++, последние 3 года увлекся Java.
Компании: Топаз-сервис, Мвм
Сдал экзамен Oracle по Java: Oracle Certified Professional
Источник: otus.ru
Как проработать архитектурную концепцию IT-проекта с помощью Attribute-Driven Design
Архитектура IT-решения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании.
Помимо проектирования IT-архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы.
Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.
Именно IT-архитектор решает, как в конечном итоге будет выглядеть информационная система — в целом и в деталях. Ему требуется найти баланс между конкурирующими требованиями и ограничениями.
Если у вас есть детальное архитектурное решение, это позволит наиболее точно оценить сроки и стоимость реализации продукта. Кроме того, появляется возможность уже на старте определить характеристики системы, которая будет соответствовать бизнес-задачам. Среди критериев качества IT-архитектуры – гибкость для масштабирования, снижение рисков, скорость работы и возможность независимого выбора подрядчиков.
О том, как выглядит день IT-архитектора, и о наиболее требовательных к архитектуре проектах мы рассказывали ранее на Хабре и в нашем подкасте.
Требования и ограничения
Наша цель — спроектировать архитектуру программного обеспечения (ПО) систематическим, предсказуемым и экономически эффективным способом. Для этого нужно определить требования к продукту.
Как правило, техническое задание (ТЗ) на разработку продукта содержит требования, но не всегда они указаны в достаточном объеме. По этой причине в числе ключевых задач IT-архитектора – сбор и анализ требований, создание дизайна архитектуры и описание решения, его проверка, а также контроль и надзор во время разработки ПО.
Рассмотрим, что входит в список требований:
1. Цель проектирования
От цели зависит, что нам нужно на старте: детальная архитектура или приблизительное представление об устройстве системы, которое позволит оценить объем и стоимость работ.
2. Атрибуты качества, нефункциональные требования
Эти атрибуты определяют свойства системы, которые она должна демонстрировать — требования к производительности, доступности, безопасности, удобству использования.
Пример: система должна работать 24х7, допускается простой не более 30 минут в месяц.
3. Функциональные требования
Определяют действия, которые система способна выполнить.
Пример: возможность выгружать данные из файла и рассылать отчеты по email.
4. Системные требования
Возникают постепенно в процессе детализации и реализуются итеративно.
Пример: авторизация, ведение журнала действий, кэширование.
5. Ограничения
Не относятся напрямую к поведению системы и не поддаются нашему влиянию. Например, у клиента есть пожелания по разработке микросервисной, а не монолитной архитектуры. Также сюда относятся требования законодательства, например, в области хранения персональных данных.
Как правило, владелец продукта заранее не имеет полного списка требований к системе, поэтому архитектор непосредственно организует процесс их сбора и фиксации. Из всех требований к системе специалист обязан выделить архитектурно значимые, которые оказывают глубокое влияние на конечное решение.
Согласно методологии ADD, сбор требований – это первый этап работы. Его назначение:
- помочь оценить стоимость и график работ;
- выработать ключевые технологии;
- обеспечить достижение бизнес-целей в процессе разработки.
Далее рассмотрим остальные этапы проектирования.
Обзор методологии
1. Собираем требования
В качестве источника могут выступать результаты опросов стейк-холдеров, анализ бизнес-целей проекта и историй использования. При этом важно конкретизировать, что имеет в виду клиент. Например, не просто «безотказная работа сайта», а «допустимый период простоя – 30 минут в месяц».
Далее мы оцениваем важность требований по двум критериям:
- ценность для бизнеса;
- степень влияния на архитектуру.
Уровни важности оцениваем по шкале HML (high, medium, low — высокий, средний, низкий). Таким образом, каждое требование будет иметь двухбуквенное сочетание. Архитектурно значимые пункты имеют обозначения HH, HM, HL, MH, MM. Стоит отметить, что большое число требований HH означает высокие риски на проекте.
2. Проектируем архитектуру
Архитектура приложений:
пиши как разработчик, думай как архитектор
На курсе проникнемся мышлением архитектора и начнем думать дальше, чем видим, чтобы код напоминал произведение искусства, а не развалины.
Научитесь писать чистые и управляемые проекты, создавать поддерживаемые системы и организовывать код.
Бесплатно сделаем все возможные ошибки во время практических заданий, чтобы потом избежать их в работе и сохранить миллионы.
18 сентября 2023
онлайн-курс на 3 мес
Почему архитектура приложений важна так же, как спасательный жилет на Титанике
В прошлом многие приложения создавались без проектирования. Это казалось удобным: никаких издержек, связанных с планированием, ускоренное прототипирование.
Но со временем сложные приложения превращались в неуправляемый крейсер, который на полном ходу несется на айсберг.
Тогда-то архитектура и стала настоящим спасательным жилетом. Приложение с хорошо продуманной архитектурой легче расширять, изменять, тестировать, отлаживать и понимать.
Архитектура приложения — это искусство. Искусство проектировать и создавать масштабные системы.
Что даёт архитектура приложений?
ускорение разработки даже сложного приложения
возможность менять структуру даже в старых версиях приложения
гибкость в изменении отдельных блоков приложения
упрощённый онбординг новых сотрудников
бесшовную ротацию разработчиков между проектами
Спикеры курса
Развивает культуру осознанного проектирования программного обеспечения
Руководит бэкенд-разработкой на Python
Более 15 лет в IT
Отвечает за архитектуру Платформы анализа больших данных
Senior software engineer
Егор Лукьянов
Имеет богатый опыт создания и разработки high-load веб-сервисов и приложений
Основные технологии: .NET Core (C#), TypeScript, MongoDB, ElasticSearch
Более 8 лет в IT
Строит с нуля компанию и платформу Torrow
Solution Architect Cohesion (Связанность и сочетаемость).
Тема II. Архитектурные границы.
Тема III. Чистая архитектура.
Шестой модуль: различные архитектурные подходы
Научимся выбирать подход к решению поставленных производственных задач, объяснять преимущества или чужие/собственные решения. Сможем находить подходящие решения для поставленных задач с учётом актуальной ституации
Тема I. Требования, предметная область. Анализ. Функциональные/нефункциональные требования.
Тема II. Архитектуные стили. Луковая, многоуровневая, сервис-ориентированная, микросервисная, event-driven.
Тема III. Архитектура приложений. MVC, MVP, MVVM, MV*.
АМА-сессия со спикерами
20 ноября в 19:00
Седьмой модуль: архитектура везде
Научимся применить знания об архитектуре к различным уровням масштаба (не только компоновка классов и модулей, но и целых систем)
Тема I. Виды архитекторов и их задачи.
Тема II. Архитектуры на разных уровнях (embedded, application, distributed system, cloud-native service).
Восьмой модуль: подводим итоги
Научимся без проблем выбирать инструмент под конкретную задачу
Тема I. Обзор основных инструментов и технологий, их место в архитектуре и принципы выбора.
Хранение данных : S3, Ceph, Posgres, MongoDB, Clickhouse, Neo4J, Cassandra, KeyValue.
Очереди : AMQP, Rabbit, Kafka, MQTT.
Языки : Python, Java, GO, C++, Javascript/Typescript.
Интерфейс : Консоль, нативные приложения, WEB: React, Vue, Angular, Jquery, гибрид, чатботы.
Инфраструктурные инструменты : docker, k8s, terraform, ansible.
АМА-сессия со спикерами
11 декабря в 19:00
Защита проекта
18 декабря в 19:00
Разработчиков и всех, кто хочет думать как архитектор
Этот курс сделает для вас то же самое, что роль Терминатора для Арнольда Шварценеггера.
Взгляните на мир глазами других архитекторов, выйдите на новый уровень в разработке ПО и повысьте свою ценность как специалиста.
Team Lead и Tech Lead
Обучить команду архитектуре — это как пересадить ее из Рено в Мерседес: тоже едет, но гораздо лучше.
Начните легко управлять изменениями в проекте и получите единое понимание архитектуры всей командой.
Для кого мы создали этот курс
Я сотрудник и хочу прокачать себя, но не знаю как сказать боссу
Вашей команде будет полезен наш курс!
Отправляйте сотрудников учиться к нам, чтобы снизить долгосрочную дороговизну и сложность разработки
Нажми на кнопку, введи почту руководителя и он получит письмо через 5 минут
Я руководитель и хочу прокачать свою команду
Я сотрудник и хочу прокачать себя, но не знаю как сказать боссу
Письмо для руководителя
Снизьте дороговизну и сложность разработки — отправьте команду на курс!
Вы получили это письмо, потому что ваши коллеги очень хотят попасть на курс «Архитектура приложений: пиши как разработчик, думай как архитектор». А мы, организаторы обучения, решили им немного помочь.
Наш курс — один из самых информативных курсов по архитектуре приложений. У него нет аналогов на рынке, которые бы так подробно раскрывали все грани архитектуры в проектах и погружали в детали, основанные на реальных рабочих кейсах.
Первый поток стартует 26 сентября. Стоимость участия от 80 000 руб. Следующие наборы будут дороже.
Но ещё дороже — совсем не пройти курс. Даже одна идея по архитектуре, внедренная по итогу, в несколько раз окупает стоимость самого курса. Не упустите возможность снизить долгосрочную дороговизну и сложность разработки!
Если вы согласны принять решение в нашу пользу, перейдите по этой ссылке, чтобы оплатить обучение ваших сотрудников на нашем курсе.
Источник: slurm.io