Transcription
Всем добрый вечер. А, друзья, я думаю, что звук у нас появился. И первое, давайте проверим наши средства коммуникаций. У нас всегда начинаются вебинары с этой части. И напишите, пожалуйста, плюсик, если видно меня, видно презентацию, слышно и видно наш чат.
Да, большое спасибо. Я вижу, что сегодня достаточное количество у нас слушателей для того, чтобы вебинар у нас был активным. И ещё раз всех приветствую на нашем открытом уроке, посвящённом курсу, а, архитектор программного обеспечения. И сегодня я на протяжении полутора часов буду с вами. Меня зовут Прощаев Сергей. Здесь есть мои контакты. Если какие-то вопросы у вас останутся или придут после окончания вебинара, то всегда можно пообщаться. Буду рад, э, нашим коммуникациям.
И, а, традиционно, э, небольшой дисклеймер и предупреждение о том, что на всех вебинарах OTUS приветствуется активное участие. Вопросы можно задавать в наш чат. Все вопросы вижу, но на них ответить могу не сразу, а для этого я буду выделять определённые м сессии вопрос-ответ. Я надеюсь, в этих сессиях мы сможем с вами обсудить и разобрать всё, что интересует.
И а наш сегодняшний маршрут вебинара. Сегодня мы поговорим об архитектурных решениях в бэкэнд разработке. Эта тема находится на, а, как правило, стыке стратегии, а, технологий и вообще здравого смысла. Мы разберём, как в целом, а, принимать решения, которые не приведут к какому-то большому комку грязи, а позволят системе расти и развиваться. Поэтому наше сегодняшнее занятие - это для, а, разработчиков, для архитекторов, для системных аналитиков в преддверии старта нашего курса. Поэтому, э-э, это важно, наверное, для многих пересечений и многих специальностей, потому что бизнес требует быстрых результатов, а команды стартуют с MVP. Архитектура часто оказывается второстепенной, и мы сегодня посмотрим, как, э, и к каким проблемам это может приводить. И главное, а самое основное - это как выстроить процесс, чтобы архитектура оставалась управляемой даже в условиях неопределённости.
И в первой части мы разберём ключевые архитектурные принципы, которые лежат в основе, а, всех популярных подходов. Затем плавно перейдём к типам архитектур от системной до архитектуры приложений и посмотрим, каким образом они связаны между собой. После этого я расскажу о курсе "Архитектор программного обеспечения", а, чтобы вы понимали, как можно углубить эти знания и получить дополнительные навыки работы в этом направлении.
И ээ давайте познакомимся. Напишите, пожалуйста, из какого города вы сегодня, э, подключились к нам на вебинар, как давно вообще работаете в IT и что планируете сегодня получить от нашего вебинара. И пока вы пишите в наш чатик, я немного расскажу про OTUS. Ous - это образовательная платформа, которая специализируется на обучении IT. Мы обучаем тех, кто создаёт наше будущее, помогаем профессионалам развиваться, новичкам в IT индустрию. И большинство сотрудников и доверяет нам своё будущее. Компания доверяет нам, соответственно, своих сотрудников и порой к нам приходят учиться даже целыми командами. Поэтому каждым занятием мы проектируем, а и создаём ваше будущее.
И, э, мы создаём также авторские онлайн-курсы для IT-специалистов любого уровня от Junior и Tech Lead. И наши программы разрабатываются на основе запросов IT-компании к кандидатам, поэтому наши выпускники получают именно те навыки, которые сейчас востребованы на рынке. Ous - это лицензированная платформа, поэтому по окончанию вы получаете официальные документы, которые подтверждают ваш профессиональный рост. Это удостоверение повышения квалификации или диплом о профессиональной переподготовке. И благодаря наличию образовательной лицензии вы можете оформить и налоговый вычеты, вернуть 13% от суммы, которая была потрачена вами на своё обучение. Кроме того, сертификат о прохождении курса всегда будет доступен в вашем личном кабинете на русском и английских языках.
А мы предлагаем широкую линейку IT-курсов, как на популярные, так и на специализированные темы. И на слайде перечислены все основные направления от программирования до тестирования. Здесь найдётся всё для junior, middle и senior специалистов. А поэтому приходите э на сайт, смотрите, что есть из того, что вас может заинтересовать. И ещё раз напоминаю, что сегодняшний открытый урок проходит в преддверии набора на курс по архитектуре и, в частности, по архитектуре программного обеспечения.
А, ну и всё. Основное обучение проходит US в живом формате. Все записи занятий материалы сохраняются в личном кабинете раз и навсегда. По каждому домашнему заданию преподаватель даёт вам развёрнутый фидбэк. А все вопросы, которые у вас возникают по ходу обучения, можно всегда задать опытным коллегам в общих чатах. А проект, который выполняется в конце курса, поможет расширить ваше портфолио. И помимо этого, программа обучения на курсах обновляется у нас каждый запуск, поэтому вы получаете все самые свежие знания, которые есть на рынке IT-индустрии.
И мы переходим с вами к основной теме нашего открытого вебинара. Давайте я познакомлюсь с теми, кто, а, кто представился в нашем чате. Так, Григорий, добрый вечер. Я Python Backend Developer с опытом коммерческой разработки, где занимался поддержкой развитием Кэнсервиса, включая оптимизацию обработки данных рефакторинг. Работал с инфраструктурными проблемами, улучшением качества данных и документации. На вебинар пришёл, чтобы лучше разобраться в архитектурных подходах. Григорий, вот большое спасибо за такое подробное представление. А, наверное, никто никогда не рассказывал про себя так много в нашем чате, поэтому приветствую вас на вебинаре и надеюсь, что ваши желания оправдаются.
А, Илья, Москва, старший 8+, банки, Госсектор. Илья, приветствую. Ринат Уфа, 7 лет Java девелопер. Предстоит разрабатывать архитектуру на своих проектах. Ринат, приветствую. Я тоже когда-то учился и жил в Уфе, закончил авиационный институт, поэтому привет Уфе и в целом всем ребятам.
Друзья, давайте переходить к основному контексту. Ещё вот небольшое такое вступление, э, к относительно темы. Я рекомендую ознакомиться со статьёй "Архитектурное решение в бэкэнде. Пять практических приёмов, которые помогают держать баланс". Эта статья вышла в преддверии в преддверии нашего открытого вебинара, поэтому а я вам а скину ссылочку на статью на Хабре, поэтому можно будет посмотреть, поделиться впечатлениями. Там можно оставлять комментарии. Поэтому, если а у вас будет какой-то интересный опыт в том, что мы разбираем в этой статье, то тоже можно будет поделиться комментариями. Я с удовольствием почитаю и попробую с вами. с вами пообщаться. Поэтому давайте двигаться дальше.
У нас, как и на всех вебинарах Отуси, а ставятся предварительные цели. Поэтому первая цель - это понимать принципы построения архитектуры. Мы разберём фундаментальные принципы, на которых держится любой современный бэкэнд. вы научитесь видеть систему не как набор определённых классов и сервисов, а как целостную конструкцию, где у каждого решения есть свои последствия. И это поможет вам избежать типовых ошибок и строить архитектуру, которую можно развивать не один год.
Вторая цель - это научиться работать с требованиями. И как вы знаете, наверное, что требования - это определённый мозг между бизнесом и кодом. Мы смотрим, а как правильно выявлять, фиксировать эти требования. Мы сможем разделять требования на функциональные, не функциональные, понимать, какие из них критичны именно для, а, в целом вашего проекта. И главное, вы научитесь использовать этот анализ как опору для архитектурных решений.
Ну и третья цель - это практические инструменты. Посмотреть, ещё раз взглянуть с призмы нашего обзора. Возможно, эти инструменты вам знакомы. Возможно, какие-то инструменты вы откроете для себя и начнёте их применять в своей повседневной практике. И для чего это важно уметь? Это, во-первых, это практическая ценность. Э, мы с вами, а, практики, и поэтому мы работаем на какой-то практический результат, который ждёт от нас бизнес как основной заказчик нашего труда. Поэтому, а, эти навыки позволяют не просто писать код, а именно осознанно управлять сложностью системы. вы станете тем специалистом, который понимает, почему система устроена именно так и может аргументированно обсуждать именно архитектурные решения заказчиком и командой. Вот в этом счёте, э, мы будем с вами двигаться.
А, и первое, с чего мы начнём, мы поговорим про, а, особенности разработки э развития архитектуры, да? То есть вот сама архитектура, она не существует в определённом вакууме, она всегда отражает бизнес-контекст. И если, кстати, друзья, напишите, пожалуйста, в чат, кто имеет опыт работы вообще со стартапами, кто когда-либо развивал какой-то стартап. Напишите, пожалуйста, как удачно ли или неудачно завершился проект. Это тоже достаточно интересно, потому что любой опыт, даже включая неудачные, это тоже есть опыт, и это дорогого стоит. Поэтому, а, буду признателен, если поделитесь историей своих начинаний, интересных проектов в нашем чате. Поэтому будет интересно пообщаться и почитать всё это дело.
Поэтому, э, как мы говорим, что, э, если бизнес растёт и быстро непредсказуемо развивается, то архитектура обязана быть тоже гибкой и адаптивной. И сегодня мы посмотрим, как это влияет на определённые технические решения, которые у нас используются в разработке, архитектуре. И первое, начнём с того, что такое стартап, э, какие ключевые признаки у стартапа присутствуют. И вот собственно говоря, почему я задал этот вопрос. Для того, чтобы вы, ээ, смогли ещё раз для себя проанализировать э что и понять, что ключевым признаком, а, стартапа являются основные темпы роста. Это не просто какая-то маленькая компания, это может быть организация, которая с нуля, а за 3-5 лет достигает миллиардных оборотов, да, потому что вот всё выстреливает достаточно непредсказуемо, никто не знает во что вылется какая-то сегодня кажущаяся безумия безумная какая-то фича, да, но тем не менее э достаточно богатый опыт того, как совсем, скажем, такие сумасшедшие проекты срывали, а подобные планки и выводили в топ закачек и загрузок в всемирной паутине, да, поэтому, а вот, говоря про стартап, именно сверхбыстрый рост определяет все инженерные подходы. У нас нет времени на идеальные решения, мы должны выдавать результат, как правило, быстрее, чем это делает традиционный бизнес.
И базовый принцип - это быстрый MVP. MVP - это минимально работоспособный продукт. Это не какая-то сырая поделка, а минимально вот жизнеспособная фича, которая решает какую-то главную задачу конкретного пользователя. И вот здесь вот как раз останавливаясь на этом задаче архитектор - это найти такой набор функций, который может именно выпустить быстро и не закрывать путь для будущего развития. Мы продолжаем, если этот MVP на стартапе у нас выстреливает, то мы продолжаем его развивать.
И базовый принцип второй - это выявление и закрытие потребностей. В стартапе мы не просто выполняем требования по ТЗ, мы постоянно ищем реальные потребности наших пользователей. И поэтому архитектура должна позволять быстро отвлекаться на обратную связь, менять функциональность, и то, что казалось важным вчера, завтра может стать уже ненужным. Поэтому система должна выдерживать и такие падения. И поэтому третий базовый принцип - это итеративное развитие нашего продукта. Мы не строим сразу весь продукт, э, мы развиваем его по частям, да. Поэтому и архитектурные решения у нас принимаются не сразу, а порциями. Поэтому мы прощупаем следующие шаги и начинаем двигаться по мере того, как снег не проваливается под нашими ступнями, да. Поэтому, а как строить MVP, да? Вот есть такая интересная картинка. такой визуал в виде метафоры. И здесь есть попытка сразу собрать целостный продукт от идеи к финальному решению за один а проход. И есть у нас э правильный путь. Идём от простого ядра через последовательные всё более полные версии. И как раз в архитектуре, а это этот подход означает последовательные, ну вот первое - это как не надо идти, да, то есть пытаться сначала нарисовать колёса, потом кузов, и в итоге мы придём к конечному финалу, когда, например, этот этот автомобиль уже потеряет какую-либо актуальность. Нам нужно двигаться маленькими итерациями. Первоначально мы делаем скейт, потом приделываем к этому скейту руль, потом помечаем, помещаем большие колёса. приделаем двигатель, делаем четыре колеса, и уже у нас полноценный автомобиль. И фактически мы проходим э всё последовательно. Мы не проектируем всё заранее и закладываем точки расширения и двигаемся эволюционно.
Главная проблема, которая у нас возникает во всех проектах - это проблема Big Ball of Mud. Это так называемый большой комок грязи. Это достаточно часто используемое выражение в архитектуре. Его можно, э, посмотреть и встретить в различных книгах. Это такой неформальный, но очень точный термин для системы, а, архитектура, которой была утеряна или отсутствует изначально. И код превращается в такую, а, монолитную, монолитно запутанную массу, где любое изменение может сломать всё, что угодно. И с таким кодом, э, зачастую достаточно сложно работать даже самим разработчиком. Система становится таким тормозом и обузой для бизнеса.
И когда проект у нас стартует, то всё выглядит достаточно элементарно. Есть пара сущностей, есть пара эндпоинтов, простая база данных. И это создаёт иллюзию, что никакой архитектуры в априоре у нас не существует. Давайте просто напишем там пару строчек кода. Но эта простота у нас является обманчивой, потому что, ээ, бизнес-логика имеет свойство накапливаться, и со временем любая система обрастает сложной логикой. Каждый новый запрос от бизнеса добавляет ветвление, добавляет исключения и какие-то костыли, связанные с особыми случаями. И если архитектура не ограничивает этот рост в правильном направлении, то логика распределяется хаотично по коду. В итоге простой, вроде бы, в начале продукт превращается в лабиринт, где никто не знает, как всё работает целиком. Появляются уникальные носители знаний в виде отдельных лиц в команде. Если это лицо, э, увольняется из команды, то команда не знает, как вносить изменения в тот блок кода, где Петя был экспертом. И поэтому страшно вносить какие-либо изменения. Поэтому вот мы приходим к такому моменту, когда, э, из процесса эволюции и развития мы получаем такой болезненный, дорогой процесс, которого можно было бы избежать, если бы мы принимали своевременно архитектурные решения и двигались правильными шагами.
А бизнес вообще зачастую, э, размышляет так, что э ну у вас же всё работает, зачем тогда это всё трогать? и не видит о том, что как нарастает внутренний долг. Архитектурный долг, он вообще не ломает продукт мгновенно, но это такая здоровенная гиря, которая может в итоге утянуть на дно. И когда потребность в рефакторинге становится критичной, бюджет уже расписан и начинается героическая латание дыр. Я надеюсь, я думаю, что не все с вами, не все сталкивались с этим, но тем не менее такая вот каждая новая фича, она требует всё больше времени и усилий, поэтому разработчикам приходится распутывать старые узлы, и в какой-то момент стоимость добавления простейшей функции может привиси превысить целиком бизнес-ценность этой самой функции, и система парадоксально превращается из актива в какую-то обузу. А блокировка стартапа через 7 лет после успешного старта, это тоже классический сценарий, когда компания вырастает до больших оборотов, но её технологическая платформа полностью застыла, и стартап, когда-то обгонявший рынок за счёт скорости, начинает проигрывать более гибким конкурентом именно из-за неспособности э развития продукта. И мы поговорим о том, как не допустить такого подхода и сохранить подвижность даже в зрелых системах.
А на старте проекта мы достаточно мало знаем о реальных потребностей наших пользователей. Мы, наверное, слабо представляем о нагрузках и узких местах. И любая попытка расписать архитектуру на год вперёд, она обречена на устаревание уже через несколько месяцев. И здесь приходится понимать, что этот факт и, а, строит процесс так, что архитектура уточнялась вместе с нашим пониманием продукта. Это как раз вот есть такая, э, такое правильное направление, которое позволяет двигаться именно в пользу такого последовательного развития продукта. И есть такое понятие, как эмерджентная архитектура. Она проявляется, а не назначается, да? То есть она вообще эмерджентная архитектура - это такой подход, при котором финальная структура системы не придумывается заранее, она вырастает из реального кода и из реальных вызовов. То есть мы знаем какое-то направляющее действие и принципы и какие-то действующие ограничения, но конкретное решение принимается только тогда, когда это накопилось, э, и мы имеем для этого достаточно информации. То есть это не хаос, это такая управляемая эволюция, которую мы планируем к использованию и управлению ей.
А неопределённость архитектуры и эмпирические оценки. А, ну вот это про то, что в таких условиях классический аналитический расчёт уступает место эмперики. Мы пробуем, мы начинаем пробовать, мы высказываем какие-то гипотезы, мы что-то измеряем, делаем выводы. Какие-то выводы подтверждаются, какие-то нет, и многие оценки становятся вероятностыми. Мы говорим о том, что, например, вероятно, здесь будет узкое место, и в ряде экспериментов начинаем или подтверждать, или опровергать. Поэтому архитектор в этом направлении учится работать с неполнотой данных и принимать решения на основе сформированных гипотез. Э, есть какие-то недоказанные факты, поэтому вот мы здесь занимаемся в большей степени исследованиям.
Поэтому, а следующая особенность - это минимум необратимых решений и как можно дольше их откладывать. Это про то, что само необратимое решение - это выбор, который потом крайне дорого и невозможно переделать. Например, протокол взаимодействия, например, сама база данных, которую мы выбираем в самом начале пути. Архитектор должен осознанно откладывать такие выборы до последнего ответственного момента, когда информации уже достаточно, потому что всё, что можно сделать опциональным, должно оставаться именно как опция и действовать как можно дольше.
Интерактивная инкрементальная разработка говорит о том, что мы, э, наращиваем систему не большими монолитными замыслами, а действуем маленькими, но завершёнными преращениями. И каждая такая операция - это законченный цикл с обратной связью. Задумали, сделали, показали, улучшили. Да, вот такой ритм именно в команде позволяет архитектуре развиваться органично, без каких-то перекосов. И классическая инженерия, она приучила нас, э, гнаться за оптимальностью. Но опять же в мире стартапов оптимальное сегодня - это устаревшее завтра. гораздо ценнее способность быстро менять направления без переписывания всего проекта. Лучше чуть меньше и эффективней, но легко изменяемый код, чем идеально настроенный, но жёсткий монолит.
И архитектурные решение аэ держим как а опционы, да? То есть, э, пока решение не стало обязательством, оно остаётся опционом. Мы держим дверь открытой. Это меняет наше мышление. Мы не спрашиваем, какое решение применять, а мы спрашиваем, когда именно мы обязаны принять это решение, что нужно ещё узнать перед этим. Такой подход именно снижает риск дорогих ошибок на ранних этапах.
И а вот здесь у нас как бы есть тоже такая схемка. Есть два полиса. Это Design и International Architecture, да? То есть здесь есть два подхода, которые не исключают, а дополняет друг друга. IGН design, он идёт от Agile манифеставит во главу отклик на изменения и работающий код, а не какие-то детальные планы. А International Architector, да, это ээ это из мира Scellet Agile, она добавляет направляющие линии. это некий такой стратегический э взгляд и технологический каркас для крупных систем. И вот на практике нам как раз нужно э совмещать, давать командам свободу адаптироваться, но при этом задавать общие архитектурные правила и как раз об этом балансе держать максимум опционов открытым. Но фиксируем ключевыми направлениями мы будем говорить на сегодняшнем вебинаре.
Когда мы говорим про варианты развития архитектуры, то в этом случае мы можем рассмотреть три, наверное, такие классические варианта э три типовых контекста. Это стартап, эта корпорация и есть эмерджентный подход. Мы про него ещё будем говорить не не одднократно, поэтому каждый диктует свои правила и определённые игры для архитектора. Разная степень неопределённости есть в каждом подходе. И понимание этого различия - это вот значит то, что мы правильно выбираем уместные практики и не применяем один шаблон на все различные варианты.
А стартап, если мы начнём рассматривать это направление, то в стартапе у нас архитектура рождается эволюционно, потому что продукт ищет свою нишу, а бизнес-модели ещё у нас не устоялась. И главный приоритет - это такая быстрая проверка гипотез. Поэтому архитектурные решения принимаются легко и должны легко меняться. А многие выборы сознательно откладываются, система проектируется так, чтобы пережить неизбежные перестройки.
А в отличие от этого корпорация она живёт несколько иначе. Да, корпорация у нас - это сложность наследства и формальные процессы. Иногда это достаточно сильно переплечено между собой. Поэтому в крупной организации архитектура редко начинается с нуля. Мы, как правило, имеем дело с существующими системами, а, различными регламентами, аа, с центрами влияния. И скорость внедрения нашего продукта в корпорации, она оказывается значительно ниже. Зато выше цена любой ошибки. Любое изменение может затронуть десятки смежных систем и тысячи различных пользователей. И здесь на первый план выходит планирование, согласование и тщательная работа с ограничениями. Здесь вот как раз основная основной подход, если здесь в стартапе мы можем работать по Ййлу, то здесь в корпорациях это, как правило, waterfall, да, это водопадная схема. И здесь планирование и согласование выходит на первый план.
Ну и вот такая эмертная архитектурная эволюция это путь, это не просто бросить всё и пусть само растёт, да? То есть это некая управляемая эволюция, которая уместна в условиях неполного знания. Мы задаём чёткие архитектурные принципы и границы, но конкретные детали наполняем по мере накопления информации. И такой подход применим и в стартапе, и в подразделениях корпораций, которые работают в продуктовой модели. Поэтому, а, вот Agile плюс водопад - это реальность, э, там, скажем, такого большинства проектов, да, потому что на практике никто не живёт в чистом джайле или в чистом водопаде, всегда есть какая-то смесь. И стратегические архитектурные решения, они требуют, как правило, глубокого анализа. и не могут приниматься спонтанно, а тактически они должны реагировать на обратную связь достаточно быстро. И вот задача архитектора в таком направлении - это как раз, э, найти работоспособный баланс, ээ, где планируем, а где адаптируемся, так как соединяем это в целостную картинку, которая даёт в итоге результат.
А какие у нас есть виды архитектур? Да, ну вот опять у нас же сегодня такой вебинар открытый, поэтому тема такая м она такая, наверное, будет сегодня общая к расхождению. Мы сегодня посмотрим на основные критерии, основные классификации, сделаем какое-то для себя, возможно, сари по тем, а, навыкам, которые у нас были. Поэтому вот первое, что мы ещё раз рассмотрим, это классификацию перед тем, как рассмотреть какие-то практические решения. Там пройдём ещё по основным критериям.
И архитектор - это не просто у нас одна роль, это целый спектр различных специализаций. Когда в компании говорят и называют кого-то архитектором, то за этим словом могут стоять совершенно разные зоны ответственности. И один архитектор может проектировать бизнес-процессы, другой архитектор может, э, проектировать сетевое взаимодействие, третий, внутреннее устройство приложений. Важно различать эти роли, чтобы понимать, кто, наконец, за что отвечает и с кем вам, как, например, там, бэкэнд к разработчику, а, предстоит взаимодействовать.
И первое - это бизнесфокусировка, да, то есть это вот так называемый архитектор, ориентированный на бизнес. Э-э, это направление Enterprise Architecture, э, которая видит картину в масштабе всей организации и в целом как системы поддерживают стратегию развития компании. А бизнес архитектор, он фокусируется на процессах, связанных с оркструктурой, о том, как по встраивается в работу всех основных людей. А, и вот этот это объединяет техническое бизнес-видение на самом высоком уровне. Это такой мост между технологиями и, например, там, советом директоров или собственниками компаний.
А второй уровень - это архитекторы, ориентированные на операционную деятельность. Ну, я бы здесь, наверное, перевёл как ориентированные, скорее всего, на эксплуатацию, да? То есть это вот именно второе второе направление. Не хотел перечеркнуть, у меня так работает указочка. А вот поэтому это такие м это такая Cloud Architecture, которая э в большинстве сейчас проектируется и используется в больших корпорациях. В этом направлении может быть и Security архитектор, который отвечает за безопасность на всех уровнях. Есть Network архитектор, который, а, отвечает за сетевое взаимодействие. Ну и вот таких ролей, под ролей может быть достаточно много. Ну, не обязательно, опять же, что это могут быть разные люди. Ээ чем больше корпораций, тем уже конкретная специализация, а чем корпорации меньше, поэтому это всё может совмещаться и в конкретном отдельном человеке.
А девелопер focused - это архитекторы, которые ориентируются на разработку. Это наша прямая такая специализация, да, те, кто вот пришёл на вебинар из разработки, из бэкэнда, возможно, техледы, вот он принимает как раз ключевые технические решения внутри уже а продукта. Есть Application архитектор, который работает на стыке нескольких приложений. Есть Data архитектор, который проектирует модели данных, ну и так далее.
Ну и а завершает направление это вендер focused. Это архитектор, ориентированный на вендера или решения, мм, которое представляет вендеры. Это такие направления, в частности, вот Solution Architect - это должность, которая собирает целостное решение часть чаще на базе продуктов конкретного вендера. Также это могут быть, кстати, open-source решения. А технический архитектор - это, м, личность, которая входит глубже в технические детали, изучает протоколы, платформы, ограничения железа. И вот эти роли, они особенно заметны в интеграционных проектах при внедрении каких-то коробочных продуктов. То есть они ярко фигурируют. Поэтому, а, наверное, вот из основного здесь всё. И мы переходим к следующему вопросу.
И чтобы не утонуть в десятках архитектурных специализаций, мы выделяем три ключевых уровня, которые релевантны у нас для эээнд разработчика. Это системная, а, архитектура, бизнес-архитектура и архитектура приложения. Вот мы достаточно много сегодня будем говорить относительно вот этих ролей. И для того, чтобы сформировать понимание границ между ними. И для того, чтобы это нам помогало задавать правильные вопросы на нужном уровне и не смешивать задачи разного масштаба.
И вот первое, мы начнём с системной архитектуры - это проектирование системы в целом. Этот уровень как раз отвечает на вопрос, из чего состоит система и как и как части взаимодействуют друг с другом. Сюда входят микросервисы, интеграции между ними внешние, а, апи, очереди сообщений, размещения компонентов по различным нодам и серверам. И системный архитектор, он как раз мыслит в терминах сервисов, э, контрактов, развёртываний, аа, и не занимается терминами классов, методов.
Есть это вот некая такая определённая настройка. А бизнес-архитектура — это такая надстройка или мост между программным обеспечением и деятельностью людей. Здесь мы уже проектируем не код, а определённые бизнес-процессы и то, как программные системы встраиваются в работу организаций. И бизнес-архитектор отвечает на вопрос: кто что делает, м, в каком порядке, где автоматизировано, где остаётся ручной труд? Это вот слой как раз критически важен для понимания ценности разрабатываемого программного обеспечения и правильной расстановки приоритета.
А архитектура приложения, Software дизайн, а — это то, что ближе всего к разработчику. Здесь уже идут классы, модули, слои зависимости и различные паттерны проектирования. Архитектура приложения определяет, как код организован внутри одного сервиса или монолита, насколько он читаем и тестирован. И на этом уровне живут наши солиды, живут DDD, э, луковые и гексагональные различные архитектуры. Всё, что помогает держать код в порядке.
Ну и Enterprise. Ещё есть архитектура предприятия — это такой более широкий контекст. Архитектура предприятия стоит над всеми тремя уровнями и, ну, она где-то стоит вот где-то, где-то вот здесь сверху. Поэтому э мы упоминаем её, чтобы все понимали, что в крупных компаниях есть люди, которые думают и на этом масштабе. Но наш фокус сегодня осознанно сужен именно до трёх практических уровней, на которых работает ээкэнд архитектор.
А как эти уровни помогают в реальной работе? Когда вы слышите задачу, например, добавить экспорт отчёта, то вы можете раскладывать её по текущим уровням. Например, на бизнес-уровне это кто и зачем получает этот отчёт, как он встроен в этот общий процесс. А на системном уровне мы задаём вопрос: э какой сервис формирует этот отчёт, куда он его кладёт, кто его забирает? И на уровне приложения уже как реализована генерация внутри сервиса. И вот такой именно трёхуровневый взгляд превращает размытые задачи в конкретные архитектурные решения и позволяет успешно выстраивать проекты.
А бизнесрхитектура, давайте коснёмся немножко её. Она у нас находится вот в этом э направлении. И бизнес-архитектура — эй, шаг, как такой к осмысленной системе. И прежде чем писать код, нужно понять, как работает м организация сейчас и как она должна работать после внедрения нашего кода. И как раз вот здесь а бизнес-архитектор, он всегда отвечает на вопрос: зачем мы это делаем? Мы начинаем фиксировать связь между действиями людей и поддерживающими их системами. И без этого слоя даже технически идеальное решение может оказаться бесполезным.
Поэтому, аэ, мы, э, фиксируем текущую, а, схему работы как AS is. А мы описываем, как процессы устроены прямо сейчас: кто кому передаёт информацию и где используются какие-то Excel файлы, где, э, двойной ручной ввод. И это не критика, это описание, э, и честная диагностика, которая выявляет узкие места, выявляет возможности дублирования, точки неэффективности. И только, а, зная AS is, мы можем спроектировать изменения, которые действительно улучшает ситуацию, а не добавляет новый слой хаоса.
Поэтому от «как есть» мы идём к «tob». Это проектируемое целевое состояние и с в которого, в которое мы должны прийти. И здесь, когда мы говорим про этот процесс, то мы описываем, как процессы будут работать после внедрения нашей системы. И вот здесь как раз важно не просто нарисовать красивую схему, а согласовать её с другими архитекторами. То есть мы должны чётко понимать: не ломает ли она какие-то смежные системы, укладывается ли в технологические ограничения? И фактически туби становится таким контрактом между бизнесом и разработкой. Мы обязуемся построить систему, которая поддерживает именно эти процессы, а бизнес обязуется принять именно эти изменения.
И бизнес-архитектор вот в этой связке он не работает в изоляции. егоби процессы должны быть технически реализуемы. Системный архитектор подсвечивает ограничения. Это такой, а, поток данных, э, который идёт по различным направлениям. И здесь мы должны чётко понимать: пройдёт ли этот поток данных через нашу шину с такой-то скоростью, э, понадобятся ли здесь какие-то асинхронные интеграции? И такой диалог на раннем этапе спасает от нереалистических ожиданий и болезненных переделок э в середине нашего проекта.
И помимо этого есть связь и с другими уровнями архитектуры. Бизнес архитектура задаёт, а контекст для системной архитектуры: то, какие сервисы нужны, как они будут обмениваться, данные, какие слей будут критичны. И в свою очередь архитектура приложения реализует требования, которые спущены, оказываются спущены сверху, да, в виде конкретного кода. Это такая трёхуровневая пирамида, которая является, а, основным инструментом, чтобы не упустить важное при проектировании.
И практический пример, э, ну, который можно здесь привести: допустим, мы автоматизируем процесс возврата товара в интернет-магазине. И, например, «как есть» — это когда клиент у нас выполняет звонок в кол-центр, оператор заполняет заявку там в «экселине», а склад получает письмо с пометкой «возврат», и всё вот это начинает бесконечно крутиться в хаосе, что-то теряться. И к чему мы следуем? А мы смотрим «туби» — это когда клиент оформляет возврат в личном кабинете, система создаёт а задачу, которая автоматически улетает на наш склад, ээ отправляет трек-номер клиенту и обновляет статус заказа. Именно такой бизнес архитектурный взгляд сразу даёт понятные требования к системам и приложениям.
И а перед нами а упрощённая, но реальная модель а целевого бизнес-процесса. Это публикация объявления о покупке компонентов в маркетплейсе. Она выполнена в нотации Archimate. Это международный стандарт для описания архитектуры предприятия. На таких схемах бизнес-архитектор договаривается с заказчиком о том, как именно люди и системы будут работать вместе. И главный участник процесса — это, а, менеджер предприятия клиента. И вся цепочка у нас запускается, а, со стороны менеджера, которому, ну, нужно найти и закупить определённые компоненты. И именно его действия и решение определяет последовательность всех шагов, которые нам предстоит автоматизировать или поддержать на уровне программного обеспечения.
А на схеме у нас есть два крупных этапа работы. У нас есть ээ менеджер сначала формирует и согласовывает требования, затем он работает с заявкой. А первый этап от потребности согласования, и он начинается с того, что менеджер формирует требования к искомому компоненту. Это ещё не публичное объявление, это какой-то внутренний документ. Затем у нас идёт обязательный шаг — это согласование, да, в реальных организациях без грипфа «согласована», закупка у нас не может быть запущена. Только когда требования согласованы, менеджер переходит к следующему блоку — это взаимодействие с маркетплейсом.
И здесь у нас выстреливает второй этап. Мы выставляем объявление и начинаем работать с с откликами. Менеджер публикует заявку на покупку компонентов на маркетплейсе. Это ключевое действие, которое становится доступным внешним продавцам. И после публикации возможен возврат на доработку. Если что-то пошло не так, э, то бизнес-процесс обязан учитывать такой сценарий. И далее идёт у нас ожидание, да? То есть у нас система должна поддерживать форматирование предложений от продавцов, э, подписку на новые предложения, чтобы менеджер мог получать этот список и выбирать подходящие и подтверждать э сделку.
А что этот процесс целиком означает для системной архитектуры? А как только у нас есть такая схема, мы можем ввести чёткие требования к сервисам. Нужен сервис управления требованиями, где их формируют и согласовывают. Второе, нужен сервис публикации заявок, а нужен механизм подписки на новые предложения и уведомления. И системный архитектор видит здесь минимум три-четыре компонента, видит асинхронные взаимодействия и необходимость хранения состояний заявки. А внутри каждого сервиса появляются свои сущности: это требования, есть сущность заявка, предложение, согласование. И мы можем сразу прикинуть модели данных. Мы можем прикинуть статусные модели и аконтракты, которые у нас могут возникать. И такая бизнес-схема, она избавляет разработчика от основных догадок: "А что делать, если требование не согласовано?" Всё, все витвления уже описанные в нашем процессе, и всё можно понять из этой документации.
Почему эээнд разработчику важно читать такие, уметь важно читать такие схемы? Потому что вот подобные диаграммы, они являются прямым источником функциональных требований и сценариев использования, потому что, как правило, не бывает таких проектов, где вы получаете функциональные требования в полном объёме. Это, как правило, вот ээ такой такая часть, которая постоянно видоизменяется, что-то вам добавляет, что-то забирает. Поэтому, а если у вас на входе есть, э, вот такая в Архимейте есть такая, м, такая схема, да, и вы умеете её, а, читать, то, в принципе, вы можете посмотреть на шаг вперёд. А вы немножко заглядываете в будущие энпоинты, можете предугадывать какие-то моменты. Это как раз резко повышает автономность разработчика, и вы перестаёте ждать детального ТЗ и начинаете самостоятельно извлекать архитектурно значимую информацию из вот этих таких бизнес-моделей.
А давайте теперь чуть глубже посмотрим на вот эту верхнюю надслойкой, надслойку — это системная архитектура. Мы перешли вот на этот уровень. И именно здесь бизнес-требования превращается в конкретное техническое очертание будущей системы. И системный архитектор определяет, из каких компонентов состоит решение, как они общаются, где развёрнуты и как защищены. И этот уровень пространства это является пространством ключевых архитектурных решений, которые сложнее всего меняются в итоге эволюции нашего продукта. Да. И основные, э, вступают функциональные и нефункциональные требования, да? То есть это вот функциональные требования говорят, э, что система должна делать. Например, пользователь может создать заказ, система отправляет уведомления, а нефункциональные — это, э, как система должна это сделать: с какой скоростью, под какой нагрузкой, с каким уровнем безопасности? И пропустить нефункциональные требования на старте — это самая такая серьёзная огреха архитектурных решений при росте системы. Поэтому, если что-то мы не заложили и поставили не на ту базу данных, э, которая должна обеспечить нам требуемую производительность, то это достаточно фатальное решение, и ошибки дорогого стоят.
А техническое решение, вторая в в системной архитектуре, техническое решение, технические решения, да, то есть это выбор технологического стека, это выбор ключевых подходов. На этом уровне мы выбираем язык разработки, а, базы данных, брокеры сообщений, какие-то оркестраторы, прочие фундаментальные компоненты. Каждое такое решение — это не просто ээ наш выбор, это осознанный компромисс между стоимостью, производительностью, доступностью и порогом вхождения в него а нашей команды. И именно технические решения, они порождают ограничения и возможности, а, в рамках которых потом живёт архитектура. аа всего приложения интеграции как компоненты а-э системы э связей, да? То есть вот современная система, она редко живёт в изоляции. Ээ мы интегрируемся, мы интегрируемся с различными платёжными системами. Мы подключаем, а, CRM системы, ERP системы. И системный архитектор, он как раз проектирует протоколы, э, планирует взаимодействие. Это будет порысту, это будет удалённый вызов хранимых процедур, это могут быть очереди сообщений, файловые какие-то обменные при обмены, прямые подключения. Поэтому ошибка в интеграционном решении, она может создавать узкое горлышко, которое заблокирует в итоге вес весь бизнес-процесс, который мы обсуждали на предыдущем слайде.
И дальше у нас идёт сетевая архитектура и архитектура безопасности. На сетевой архитектуре здесь решаются вопросы: что у нас находится в публичной подсети, что находится в приватной, как настроены должны быть балансировщики, м, будет ли у нас VPN или будут какие-то межсетевые экраны? И даже в самой идеально написанный микросервис, он не будет работать, если к нему нет сетевого доступа из-за ошибок э в архитектуре. И здесь вот как раз разработчику полезно понимать этот уровень хотя бы в общих чертах, чтобы не валить всё на то, что виновата сеть, да, и о том, что у нас что-то не работает.
И архитектура безопасности, наконец. Безопасность вообще-это не отдельный продукт, а сквозной аспект системной архитектуры. Мы проектируем аутентификацию, авторизацию и шифрование каналов. Э-э, мы проектируем защиту данных, э-э, а проводим аудит действий, и любая интеграция, любой новый компонент, он должен проходить через призму безопасности, а иначе там дыра в одном сервисе, она компрометирует всю систему целиком. И, э, это приводит к тому, что системная архитектура, она вот является таким основным базисом для построения устойчивых систем.
Аа у нас есть два главных документа системного архитектора. Это есть SRS и ADR. И на этом слайде мы видим два артефакта, которые системный архитектор создаёт и поддерживает. SRS — это Software Requirment Specification. Это спецификация требований. Это формальный документ, который фиксирует, что именно система должна делать с каким качеством. И второе — это Architecture Decision Record. Это выбор решений. Это журнал архитектурных решений, в котором зафиксированы выборы, их причина, компромиссы, отвергнутые альтернативы. И вот здесь у нас как раз на слайде разбираются эти два фундаментальных понятия.
В Срсе мы описываем интерфейсы, аэ, которые интерфейс системы: как наша система взаимодействует, да, то есть как с ней взаимодействуют пользователи, другие системы. А функциональные требования отвечают на вопрос, что система делает. Это сценарии, какие-то бизнес-правила. Нефункциональные требования фиксируют атрибуты качества: производительность, доступность, безопасность, масштабируемость, удобство сопровождения. И, э, СРС, э, критически важен для архитектора. Без того, как мы фиксируем требования, любое архитектурное решение у нас повисает в воздухе, непонятно от чего отталкиваться, куда мы движемся. И СРС это как раз даёт чёткую рамку. во во что система у нас должна превратиться. И когда требования задокументированы, то архитектор может аргументированно защищать своё решение перед заказчиком или перед командой.
Ар — это, ещё раз, там фиксация и выбор конкретных решений. Это не многостраничный документ. Это, как правило, такой короткий табличноориентированный файл, который живёт рядом с кодом и помогает новым членам команды понять, почему здесь именно так. И мы видели пример адр на одном из слайдов. Это когда дата, статус, контекст, решения и последствия, да? То есть это такой некий исчерпывающий, но компактный формат.
И а у нас вот тоже есть пример нашей схемки. Здесь бизнес-аналитики формируют бизнес-требования на основе общения с заказчиком и пользователями. Это такие сырые, а данные для дальнейшей работы. Бизнес-архитектура, а описывает бизнес-процессы, связи пооздеятельности людей, создаёт контекст для системных решений. Заказчик согласовывает бизнес-требования, контролирует выполнение работ и принимает результаты. Он такой главный стейкхолдер всего этого процесса. А системный архитектор — это такой центральный узел, а который формирует АДР, перерабатывает бизнес-требования функциональные, нефункциональные, разрабатывает архитектуру, а, системы, планирует проект и работает сразу с несколькими, а, входами от бизнес-аналитика, от бизнес-архитектуры, от заказчика. И, э, на выходе подаёт целостный технический план. э, который, ээ, фактически создаёт создаётся этой ролью, которая требует постоянного переключения между языком бизнеса и языком технологий. Такой некий технологический мостик, который, а, формирует важные артефакты.
А поэтому, несмотря на то, что даже если вы сейчас, например, ещё не архитектор, а, например, разработчик, тоже полезно понимать эту схему, потому что вы ежедневно сталкиваетесь с требованиями и решениями, которые кто-то принял. И понимание цепочки бизнес-требования, э, СРС и АДР, оно помогает видеть своё место в процессе и задавать правильные вопросы. То есть это вот как раз первый шаг к тому, чтобы самому начать формировать адрки и участвовать в проработке основных требований, которые стоят по задачам между командами.
А функциональные требования — это, как мы сказали, прямое описание того, э что система должна делать для решения бизнес-задач. Они у нас не придумываются разработчиками, а выводятся из бизнес-требований, которые сформировали аналитики и согласовал в итоге наш заказчик. Каждое функциональное требование — это ответ на вопрос: какую именно возможность мы представляем пользователю или с нашей смежной системе? И а здесь вот как раз АДР у нас формирует, фиксирует ключевые технические выборы. Эти выборы прямо влияют на формирование функциональных требований. Например, мы можем написать в ДРИ, что используем асинхронные очереди для интеграции с платёжными шлюзами. И это будет порождать функциональные требования, что система, например, должна обрабатывать колбки от шлюза и из очереди обновлять статусы наших заказов. Без адрок требования остаются такими достаточно абстрактными, а с АДР они обретают техническую конкретику, которую можно сразу брать уже и в разработку.
И здесь вот у нас на слайде перечислены типовые категории. Это не просто список, это такая карта, по которой, а, архитектор проверяет, всё ли учтено. А есть бизнес-правила, например, там заказ, а, свыше 100.000 руб. требует дополнительного согласования. Есть, э, административные функции. Администратор может заблокировать учётную запись пользователя и управление данными. Это, например, там система хранит историю изменений статусов заказа за последние там 3, например, там 5 лет. Ээ, поэтому, а, от функциональных требований и после того, как мы всё проработали, мы переходим к череде нефункциональных требований, которые мы сказали, являются тоже не малозначными, да? То есть это вторая половина СРСА. Это требования, которые влияют на архитектуру и создают определённое направление развития продукта. Если функциональные требования определяют, что делает система, то нефункциональная определяет, как хорошо она это делает. Именно здесь формируются атрибуты качества, которые потом определяют выбор баз данных, технологий развёртывания, протоколов и даже определённых, а, структур кода.
И вот эти три главные атрибуты качества. У нас представлены три перспективы. А первое — это внешнее качество. То, что могут заметить пользователи и смежные системы, есть внутреннее качество, это всё, что связано с тем, с чем живут разработчики. И есть качество использования. Это так называемый фронтенд. Ээ и архитектор здесь должен уметь работать со всеми тремя, потому что провал, например, в одной группе делает систему непригодной к дальнейшей эксплуатации. И мы рассмотрим каждую группу отдельно для того, чтобы можно было, а, идентифицировать эти требования в своих проектах.
И, э, первое — это внешнее качество. А здесь есть надёжность, производительность, масштабируемость. Сюда входит у нас, ну, их, на самом деле, достаточно много. Есть даже определённые отраслевые стандарты, мм, которые покрывают это направление. Надёжность и устойчивость к сбоям и восстанавливаемость — это про то, чтобы система продолжала работать, даже если что-то пошло не так. Производительность — это время отклика и пропускная способность, а масштабируемость — это способность расти без деградации этих основных показателей. -э внешнее качество, э-э доступность, безопасность и контролируемость — это про uptime. И здесь безопасность охватывает как раз конфиденциальность, целостность данных, аутентификацию, защиту угроз. Это не опция, это есть определённые обязательства. И здесь же есть и контролируемость. Контролируемость — это возможность управлять системой в продакшене. Мы не просто выставляем продукт, который хаотически как-то там взаимодействует с какой-то средой. Мы должны выполнять мониторинг. Мы должны иметь возможность логировать результаты деятельности нашего продукта, выполнять трассировку, получать различные алерты и общаться и взаимодействовать с панелями администратора.
А внутреннее качество, ну, здесь у нас представлены четыре основные категории. Эта группа напрямую влияет на стоимость развития и сопровождение. Э безошибо безошибочность — это не только отсутствие багов в моменте, но и устойчивость к регрессиям. Если мы вносим какие-то изменения, изменяемость кода определяет, насколько легко мы можем добавить новую функциональность и тестируемость. Это то, насколько просто покрыть код автотестами. И, а, бизнес часто не видит внутреннего качества напрямую, но ощущает его через скорость поставки новых фич. И если код трудно изменять и невозможно быстро тестировать, то каждая новая задача, она затягивается, а риск поломок у нас значительно возрастает. И инвестиции как раз во внутреннее качество — это есть инвестиции в определённую предсказуемость и, а, скорость разработки.
А качество пользователя, да, вот здесь представлен фронтенд, это больше про фокус на UX. Это как раз группа выходит за пределы чистого бэкэнда, но системный архитектор обязан мм учитывать и её особенности при проектировании. А результативность здесь может показывать, ну, опять показывать, может ли пользователь решить свою задачу, скорость обучения, насколько быстро новый пользователь у нас осваивается при работе с нашим продуктом, эффективность, точность, утомляемость и удовлетворённость такой кучи факторов, которые влияют на то, на то, чтобы система помогала, а именно не мешала, особенно в сценариях интенсивной работы.
И вот есть такая, а, большая таблица нефункциональных требований. Э, в таблице показывается ещё более широкий спектр атрибутов, а, от accessibility до traceability, включая, м, dissestor recovery, delyability, documentation, ну, всякие, да, то есть вот эти по окончаниям. Все эти термины пришли из стандарта качества ISO 2510 и практик слита джайла. И ключевая основная мысль — это вот набор основных атрибутов. У разных проектов он является примерно стандартным и примерно одинаковым, но их приоритетность радикально может отличаться. А для банковского приложения, например, безопасность аудит будет на первом месте. для какого-то стримингового сервиса производительность и масштабируемость будет превалировать над безопасностью. Для внутреннего инструмента администратора можно пожертвовать качеством использования, но критически важно важна контролируемость, и архитектор должен, а, сознательно выбирать, какие атрибуты являются ключевыми, и в явном виде фиксировать эти приоритеты, потому что именно они будут формировать все ключевые архитектурные компромиссы, которые в целом лягат на развитие нашего продукта.
А как с этим работать на практике, да? То есть, ну вот какая есть рекомендация? Не пытаться достичь всё-таки совершенства по всем атрибутам. Это невозможно, да и фактически является ненужным. То есть нельзя создать такую универсальную мегасистему, которая будет закрывать. Поэтому рекомендуется первое в диалоге собрать а основных заинтересованных лиц и определить, например, пять критичных качеств для вашей системы и именно их закладывать в архитектурные решения и проверки, которые сформируют такую основу для развития вашего продукта.
Чуть более глубже давайте рассмотрим АДР, ээ, посмотрим, как и что они из себя представляют. Architecture Decision Record — это инструмент, который спасает от архитектуры, архитектурной амнезии, да, потому что, а, в разработке очень часто возникают такие ситуации, когда вспоминаешь, что проектировал неделю там или месяц назад, и мысли начинают путаться, начинают забываться, почему именно выбрали это решение, а не иное. Ну вот здесь как раз, э, Architecture Decision Record — это как раз короткая, но строгая запись об одном принятом архитектурном решении. Она как раз фиксирует то, какие варианты мы рассматривали и какой был выбран, почему. И это позволяет вот экономить время на повторном анализе многих вещей, потому что, ну, вот опять же процесс развития продукта, он достаточно такой эволюционный, и нам приходится по спирали постоянно приходить в эти же точки и вспоминать, а почему мы находимся на этом векторе и почему это было принято так или иначе. Э, поэтому АДР позволяет документировать причины принятия и отклонения тех или иных решений. Почему не кавка? Например, там запись ВДР даст готовый аргументированный ответ и позволяет, а, задокументировать эти причины.
А структура ДР у нас вот на примере, э, нашего слайда, она должна содержать основные разделы. Это решение номер четыре. Есть, э, дата м там 16 апреля от какого-то двадцатого года есть статус «accept». Это означает, что решение принято и действует эта чёткая метка. Она позволяет быстро отделить актуальные решения от устаревших. И если решение впоследствии пересматривается, создаётся новые др, а в старом статусе меняется на «supersested». А раздел контекста объясняет основную м проблему. Например, перезагрузка сервиса в режиме watch занимала слишком много времени. А, нон был неоптимальным для этой задачи. Хороший контекст — это вот не пересказание всей истории, а чёткая фокусировка на том, какая конкретная ситуация требовала архитектурного вмешательства. И это помогает новым членам команды мгновенно понять, ради чего вообще принималося это решение. И decision — это само решение. Здесь решение сформулировано предельно конкретно. Мы будем использовать notf для режима наблюдения за файлами сервера. Никаких размытых формулировок никаких, «возможно», или «в перспективе». ADR — это про фиксацию, а, фиксацию уже совершённого выбора. И такая, а, чёткость, она устраняет двухсмысленность. Разработчик, читая АДР, сразу узнаёт то, что используется у него в проекте.
А последствия — это пятый раздел, который есть у нас в ДРЕ. Э-э вообще АДР, ну, скажем так, чем отличается хороший Адр от, э, отличного АДР? Отличный АДР, честно, говорит, не только о плюсах, но и о минусах и об ограничениях э принятого решения. здесь позитивное последствия, например, там перезапуск, э, вот здесь вот по-английски, да, то есть перезапуск пере перезапуск сервера стал до трёх раз быстрее, там 10 секунд вместо 30тридцати. А если бы были и негативные замечания, например, там потери совместимости с каким-то C окружением, то они тоже были бы здесь в пятом разделе зафиксированы, чтобы команда не наступала повторно на грабли. Почему? Вот. А многие задают, ээ, вопрос, особенно начинающие разработчики, почему Адр — это там не бюрократия, да, то есть, а наоборот, это такая суперсила команды, потому что Адр живёт именно прямо в репозитории. Она живёт рядом с кодом в простом текстовом формате. Это не какой-то многостраничный документ с грифами согласования. Его как раз вот адр пишут разработчики. Э они пишут на ходу по мере принятия каких-то значимых решений. Каждое такое решение, оно становится коллективным и не э фиксируется, и не у, скажем так, нет какой-то какого-то устного, ну, то есть всё, что написано пером, не вырубишь топором. Наверное, вот здесь самое, наверное, будет подходящее.
А следующий аспект — это C4 диаграммы, которые мы тоже разберём. Этот инструментарий, он достаточно тоже удачно сочетается для проектирования систем. И C4 расшифровывается как контекст контейнер компонент код. Это вот как раз 4C. Там по-разному их именуют, но смысл заключается в том, что это четыре буквы C, а которая обозначается в этой стратегии. А это и это не очередная сложная нотация, это наоборот способ делать архитектуры видимой и обсуждаемой для всех участников нашего проекта. И сегодня мы разберём, э, самый обзорный уровень этого м архитектура — это контекст, это уровень C1. А эта система представлена как единая целая. И на этом уровне мы видим разрабатываемую систему как один прямоугольник, который у нас вот, например, взаимодействует с остальными системами. Цель здесь — это ответить на вопрос: кто пользуется системой, с с чем она связана и как взаимодействует и какие данные передаются? И диаграмма C1, она должна быть понятна любому стейкхолдеру, от разработчика до заказчика, а, который никогда не видел код. И, э, читаем диаграмму, смотрим роли людей вокруг системы. На схеме мы видим, а, человеческие
роли. У нас есть роль менеджера. У нас есть роль системного администратора. Есть получатель чего-либо. А, и каждая роль, она у нас стилизируется определённой иконкой. Они представляют разных пользователей с разными потребностями и правами. Это сразу даёт понимание, для кого мы строим нашу систему.
И все эти пользователи, они у нас, да, ещё вот есть там и поставщик, и разработчики ещё есть тоже. Они тоже являются э-э факторами, которые влияют и взаимодействуют с нашей системой. И все они взаимодействуют по-разному. Эти взаимодействия дальше превратятся уже в функциональные требования по мере продвижения к сверху вниз, да. Вот мы рассматриваем с контекста.
И разрабатываемая система, она не живёт в вакууме. На диаграмме у нас есть identity провайдер, identity севис. А, это система лицензий, ээ, это могут быть банковские системы, это могут быть сервисы внутренних закупок. И каждая внешняя система - это полноценная интеграция, которую нужно проектировать и согласовывать. Границы системы чётко обозначены, и сразу видно, что находится под нашим контролем, а что нет.
И, э, C1 - это такая карта, которую показывают бизнесу для того, чтобы договориться о границах проекта. И вот эта карта с уровнем C1, она позволяет избегать ситуации, когда заказчик уверен, что система делает всё, а команда разрабатывает только ядро. И такая вот нестыковка видна у нас мгновенно.
А бизнес-архитектура даёт нам процессы и роли, и вот они уже у нас на диаграмме в виде находятся в виде людей. А системная архитектура задаёт внешние интеграции. Они здесь видны в виде соседних систем. C4 фиксирует требования, C1 фиксирует общий контекст, в котором эти требования будут реализованы. И всё это связывается в единую картину.
И на следующем шаге мы заглянем внутрь нашего прямоугольника и покажем уже уровень а контейнера. А затем мы посмотрим на компонент, где детализируем внутренности каждого контейнера. И наконец у нас уровень кода. Э, если это действительно нужно, то мы опускаемся на этот уровень. Ну, а вообще уровень кода является такой определённой опцией, потому что код - это такая быстро изменяющаяся ээ быстро изменяющийся артефакт, который вот на схемах не проектирует. Его начинает писать сразу с уровня компонентов. Поэтому мы вот, наверное, тоже сегодня остановимся на уровне до уровня компонентов.
Поэтому, э, опустимся на уровень, э, C2. Здесь мы уже представляем, а, контейнер. Наша схема приобретает, э, дополнительные дополнительные, э, как сказать, э дополнительное окружение, да? То есть, э, уровень контейнера показывает, из каких крупных технологических блоков состоит наша система. И контейнер аа в терминах C4 это не докер, а это такое автономно развёртываемая единица. Это может быть веб-сервер, это может быть мобильное приложение, база данных, отдельный микросервис. И здесь, ээ, именно мы фиксируем основные технологические решения, показываем, как части системы распределены между собой.
C2 нам даёт ответ на вопрос, как система разбита на развёртываемые части, кто с ними общается. Этот уровень одинаково понятен разработчикам, девопсам, техледам смежных команд. И с такой диаграммой достаточно легко обсуждать масштабирование, конфигурацию и границы ответственности команд.
Э, на этой схеме мы тоже видим, а, пользователей, которые взаимодействуют с системой через несколько клиентских, э- SPA приложений. У нас, а, есть SPA, есть десктоп, есть мобильное приложение. А SPA - это у нас одностраничное веб-приложение, которое обращается к нашему к нашему бэкэнду. Это всё показывает, что система уже на старте является многоканальной, и архитектор должен быть готов, а обеспечить консистентность поведения через разные фронтенды.
У нас есть единая точка API Gateway. Это точка входа в бэкэнд. Все клиенты обращаются к единому API Gateway. Это стандартное решение для маршрутизации. И Gateway сам по себе является тоже контейнером со своей зоной ответственностью. И здесь необходимо тоже скрыть внутреннюю структуру, защитить бэкэнд-сервис и упростить клиентскую логику. Это тоже важное архитектурное решение, которое влияет на безопасность, производительность и управляемость всей системы.
Бэкэнд-сервисы внутри, ну, опять же, у нас вот такая общая схема маркетплейса есть. Внутри мы видим несколько контейнеров, которые реализуют основную бизнес-логику. Это есть common app, есть rating API, ядро маркетплейса, различные адаптеры к внешним системам. И каждый из них - это независимо развёртываемый сервис, который можно развивать, масштабировать и отлаживать отдельно. И такой ээ покомпонентный взгляд он уже начинает напоминать целевую архитектуру, о которой мы поговорим аэ чуть чуть позже.
И на схеме показано у нас адаптер для взаимодействия с Identity сервером. А, есть адаптер для почтового сервиса систем, а, систем, э-э, с какими-то внешними API партнёров. И вот эти адаптеры как раз они изолируют, а, детали внешних протоколов и позволяют основным сервисам работать в едином стиле. И архитектор осознанно выделяет их в отдельные контейнеры, чтобы смена какого-то внешнего поставщика не привела к переписыванию основной бизнес-логики, потому что ядро у нас должно быть основное и всегда должно переиспользоваться при правильном проектировании архитектуры.
И, э, мониторинг тоже у нас вынесен в отдельный блок. Это говорит о таком серьёзном отношении к наблюдаемости. Это не просто по схеме прикрутим потом, а это такое некое архитектурное требование. И мы обязаны видеть, что происходит с системой в реальном времени. И наличие такого контейнера подчёркивает, что мониторинг - это неотъемлемая часть поставки, а не какая-то факультативная надстройка.
И фактически вот диаграмма контейнеров, она э позволяет принимать архитектурные решения. И вот глядя на такую схему, мы сразу можем обсудить и выбор технологий, и что у нас под SPA, и на чём написан API Gateway, и такой какой у нас какой протокол между взаимодействием между базами. Это всё достаточно хорошо просматривается в плане зон ответственности.
А, ну и следующий у нас подход - это компонентный подход, это уровень C3. Мы спустились ещё на минус один уровень детализации. Теперь у нас не вся система, а и не набор контейнеров. Это внутренности одного конкретного контейнера, который у нас представляет API Gateway. На этом уровне архитектор уже показывает, из каких функциональных блоков у нас состоит наш контейнер, как они связаны, как реализуют его зону ответственности. И в отличие от следующего уровня код, здесь мы всё ещё говорим о крупных строительных блоках, а не об отдельных классах и интерфейсах.
И компонент - это вот как раз не класс и не микросервис в терминах C4. Компонент - это набор связанной функциональности внутри контейнера обычно, которая развёртывается как часть этого контейнера. И это может быть, а, целый набор классов, которые объединены одной ответственностью. Это может быть, например, обёртка, а, там какая-нибудь там API V2, да, вторая версия. Поэтому это может быть адаптер какой-то к email-сервису, да, то есть вот, э, который позволяет отправлять эти сообщения. И границы компонентов, они определяются архитектором так достаточно осознанно, исходя из принципов высокой связанности внутри них и низкой связанности между ними.
И, а, здесь мы вот на нашей диаграмме видим, что Gateway у нас отвечает за приём запросов от клиентов и дальше выполняет их последующую маршрутизацию. Сам устроен не монолитно, а внутри выделены определённые компоненты. Есть API второй версии, Log API V1, а Supp - это разные версии, а и аспекты обработки API запросов. И такое вот разбиение, оно как раз помогает команде развивать разные части Gateway, независимо и не создавая конфликтов при доработках.
И, э, компонент, ну, и здесь вот дополнительно есть ещё бизнес-компонент, бизнес-логика, да? То есть это, а, бизнес-логика, которая использует цепочку обязанностей. Вот здесь есть Chain of Responsibility. М, это такой тоже архитектурный паттерн, а-а, который позволяет гибко собирать последовательность обработчиков для каждого запроса и вынесение логики цепочек в отдельную библиотеку. Компонент - это как раз пример удачного такого разделения ответственности, которое упрощает и последующее тестирование, и упрощает при использовании.
А компонент у нас также присутствует и здесь, и модели у нас есть внутренние модели. Мм, компонент-модель содержит данные, с которыми работает наш контейнер. Компонент э репозиторий, а, содержит, ну, вот здесь контроллер, репозиторий, да, то есть репозиторий отвечает за взаимодействие с базами данных, изолирует детали SQL и позволяет остальным компонентам работать с абстракцией целого хранилища. При этом мы можем хранилище заменить, и остальная часть у нас останется без изменений. Адаптер email, про него мы говорили, это компонент, который инкапсулирует логику отправки писем через внешний email. Log library - это компонент для логирования, который, вероятно, используется всеми остальными компонентами нашего контейнера. И выделение адаптеров и инфраструктурных библиотек в отдельные компоненты, оно как раз позволяет делать систему, а, достаточно гибкой.
А какие есть ещё помимо этого инструменты архитектора? Мы рассмотрели C4. Это достаточно мощный и лаконичный способ визуализации архитектуры, да, но это не единственный инструмент. Э, есть достаточно большое количество различных инструментов. И здесь есть представил у нас представлен Archimate. Это язык бизнес, так, э, язык бизнес архитектуры. Мы видели с вами пример Archimate для при разработке бизнес-процесса. Смотрели, как с помощью него появляется результат публикации заявки. Это такой открытый стандарт для описания архитектуры предприятия. UML и различные представленные диаграммы - это множество типов диаграмм. На слайде у нас здесь перечислены основные э диаграммы. Они позволяют также спроектировать модель предметной области и показать, какие сущности обмениваются сообщениями. И вот в этом плане фактически два этих инструмента, они образуют такое ядро инструментариев для архитектора, посредством которого он может описать любую систему и те архитектурные решения, которые им были выбраны.
Так, друзья, у нас, к сожалению, время немножко поджимает, и я бы, наверное, сразу перешёл к презентации нашего целевого курса. С учётом того, что мы сейчас, ну, материал достаточно объёмный, тем более сегодня ещё такой общий открытый урок, да, поэтому вот всё, безусловно, здесь не помещается в сегодняшний тайминг, но я бы хотел представить, где всё это у нас возможно, и подчеркнуть все эти знания, которые у нас не ложились, не уложились в сегодняшний контекст нашего вебинара.
Ещё раз напомню, что это открытый урок курса "Архитектор программного обеспечения". И мы сегодня как раз разберём, что представляет из себя этот курс, потому что это вот частичка, небольшая частичка знаний, которые мы сегодня затронули в плане погружения в архитектуру. Это вот далеко не низкоуровневое, это сегодня такое общая абстракция, которую мы затронули на весь курс. Это достаточно такой он, а практикоориентированный. И здесь я бы хотел рассказать об основных подходах и основной целевой аудитории, на который ориентируется данный курс.
Ну, во-первых, э сам курс, он называется "Архитектор программного обеспечения". Это программа, которая формирует целостное понимание современных, э, архитектур. Курс охватывает весь спектр компетенций от принятия архитектурных решений до построения отказоустойчивых и масштабируемых, э, систем. Он подойдёт как разработчикам, которые хотят расти до уровня архитектора, и также подойдёт для уровня для действующих архитекторов, которые желают систематизировать свои знания.
А здесь вот есть ссылочка на страничку этого курса лендинговую. Там же есть возможность пройти вступительное тестирование. И м как я уже сказал, что курс будет полезен разработчикам, frontend разработчикам, э будет неплохо а подходить для fullstack специалистов, системным аналитикам, архитекторам по лидам. Разработчики здесь получают целостное понимание принципов паттернов проектирования. А аналитики получают возможность формулировать технические требования, так как, чтобы они были понятны всей командой. Архитекторы - это получение дополнительных навыков, создания высокоуровневых концептуальных моделей. Поэтому вот курс такой достаточно универсальный с точки зрения различного приложения, э, различных ролей в команде.
И что конкретно может дать этот курс вам? Во-первых, вы освоите построение отказоустойчивых и модифицируемых масштабируемых систем. Научитесь принимать, применять на практике архитектурные паттерны Driving, DDD, Event Sourcing, CQRS, да, разберётесь в подходах к построению API. Ээ, глубоко разбирается оркестрация, хореография, версионирование и специальные архитектуры, такие как микрофронтенды, мобильные, Lambda, ETL, э, паттерны наблюдаемости. Это всё вот находится во флаконе этого курса.
Формат обучения - это вебинары, два интерактивных вебинара в неделю по два академических часа. Все записи, материалы сохраняются навсегда в вашем личном кабинете. В среднем раз в 2 недели выдаётся домашнее задание. И заключительный месяц он посвящён выпускному проекту. Это проектирование реальной системы с консультациями преподавателей, менторов. И выпускной проект становится сильным дополнением в вашем портфолио и позволяет закрепить все полученные знания и умения, которые вы сформировали на курсе.
А старт курса 26 мая, продолжительность обучения 5 месяцев. После успешного выпускного проекта выдаётся удостоверение о повышении квалификации, так как OTUS имеет образовательную лицензию, и вы не только приобретаете знания, но и получаете официальный документ, который подтверждает вашу квалификацию.
А, ну и сама программа. Хотелось бы коснуться основных модулей. Первое, в модуль "Введение" можно перейти на слайд на лендинговую страницу. Вот здесь есть выпадающие списки, поэтому можно более детально посмотреть. А первый модуль, он закладывает фундамент. Мы говорим о том, что такое архитектура и архитектурные решения. Изучаем основные процессы принятия решений, различные представления архитектуры, которые помогают описывать систему с разных точек зрения. И после модуля введения вы уже сможете подготовить первое домашнее задание - это собственное архитектурное описание, которое в дальнейшем будет вот обрастать определённым архитектурным мясом таким для того, чтобы сформировать полноценное решение.
Следующий модуль - это тактики работы с атрибутами качества и архитектурных решений. Здесь, ээ, модуль достаточно объёмный и посвящён практическим тактикам управления проектом и качеством системы. Здесь разбираются модели распределения ответственности. Это SOLID, Grasp, DDD, тактики работы с модифицируемостью, отказоустойчивостью, масштабируемостью, безопасностью. Также рассматриваем взаимодействие на основе сообщений и производственные процессы сопровождения. Всё, что нужно для построения действительно надёжных систем.
Модуль "Специальные архитектуры" - это третий, э, модуль - это модуль, посвящён паттернам для определённых классов систем. Это микросервисы, фронтенды, микрофронтенд архитектуры, модели хранения данных и отдельная тема - это мобильные архитектуры. Здесь разбирается подход, а, к проектированию Big Data и ETL процессов. также архитектура для машинного обучения. Вы здесь, в этом модуле, получаете широкий кругозор, позволяющий выбирать правильный архитектурный стиль под конкретную бизнес-задачу.
И, э, модуль "Проектная работа" - это финализация ваших полученных знаний. Это заключительный месяц. Он посвящён самостоятельному проектированию системы под руководством преподавателей. Вы выбираете тему, прорабатываете её и защищаете перед экспертами, демонстрируя полученные на курсе навыки. Это не просто учебная задача, а возможность именно создать полноценный архитектурный артефакт для своего портфолио и для дальнейшего карьерного роста.
А само обучение, э, как мы уже говорили, проходит в формате живых вебинаров. Ээ все записи остаются у вас навсегда. Э, есть контакт с преподавателями, есть нетворкинг, где можно всегда задать вопрос опытным коллегам. И программа обучения на наших курсах, она обновляется каждый запуск. Мы смотрим, что есть интересного в мире IT, и вносим изменения мм в программу каждого старта. Поэтому у нас не бывает двух одинаковых запусков, поэтому новый старт - это тоже обновлённая программа по этому курсу.
Ну и ещё раз QR-код для получения для перехода на лендинговую страницу. Там есть возможность получить консультацию, как присоединиться к ближайшему старту обучения, который стартует 26 мая. И ещё раз продолжительность 5 месяцев.
Также я хотел представить э подведение основных итогов. Мы сегодня понимаем принципы э построения архитектуры. Мы их разобрали. Мы можем работать с нашими основными требованиями, умением, а, можем показать, э, из, ну, частично разобрали, как пользоваться инструментами, и фактически заложили основу для, а, построения архитектурных решений на базе основных направлений. Ну вот, наверное, это так несколько абстрактно, но тем не менее я думаю, что общая м общая информация у вас должна остаться.
А следующий открытый урок 21 мая мы разберём такой подход, как архитектурное решение API Gateway. Посмотрим, как и для чего нужен этот компонент. Достаточно тоже такой интересный э вебинар. Поэтому рекомендую, если ещё думаете, пойти ли учиться на это направление, то можно ещё поприсутствовать ещё на одном открытом вебинаре. Мы дальше поговорим о API Gateway как о некой точке входа в наш распределённый бэкэнд, посмотрим лучшие практики и поговорим ещё об архитектурных вызовах и решениях.
Дополнительно я бы хотел прорекламировать наш канал OTUS IT News, который действует в Telegram, на платформе Telegram, да, поэтому здесь в этом канале публикуются анонсы, экспертные советы и проекты выпускников. Есть много полезного контента для профессионального роста, поэтому тоже можно подписываться, переходить и быть в курсе наших событий.
А, друзья, запомните, пожалуйста, опрос о нашем мероприятии. Мы все вопросы, которые у вас поступают в обратную связь, берём и стараемся на них отвечать. Так, сегодня у нас мы ещё не в Максе, да? Давайте я немножко чатик почитаю, потому что материала было много и ээ немножко не успел, увлёкся, поэтому в Максе у нас, по-моему, что-то есть, точно не помню. Меня точно нет в Максе. Вот поэтому здесь не могу сказать, но в Телеграме всё это работает, поэтому подписка есть, поэтому можно заходить и смотреть.
Так, Сергей, ответы на вопросы из чата будут, друзья. Ну, смотрите ещё раз, вы получите запись вебинара, поэтому есть какие-то вопросы, я просто физически не успел ответить. Есть мои контакты, можно просто продублировать. Я буду рад с вами пообщаться.
Сергей, есть C4 плагин для PlantUML со своим DSL? Да. Ну да, сейчас инструментариев достаточно много. Плюс, смотрите, есть, э, много различных решений, в которых вот эти плагины уже работают с агентами, поэтому все эти вещи достаточно адаптивно позволяют, э, человека читающим языком написать то, что вам необходимо построить. И здесь с точки зрения применения основных моделей, это вот, конечно, на порядок выше. А так можно показать диаграмму C4. Так, ну мы смотрели здесь, наверное. Это, наверное, это, наверное, с перед тем, как мы, наверное, перешли, скорее всего.
Михаил, есть ли DSL архитектуры помимо структура SC4? C4 модель по сути прикольная, но а представление её как в UML убогое. Ну, смотрите, обычно C4, э, вообще, ну, как бы её, наверное, вот в чисто архитектурных решениях не всегда раскладывают именно на все четыре компонента, на четыре слоя. Обычно бывает такое, что достаточно, например, там какого-то определённого, например, там C2 среза, на котором вы, мм, который понятен вашей команде и который вам позволяет донести все ваши основные моменты до э заинтересованных пользователей, да. Поэтому в этом плане здесь просто можно, это не факт, что надо делать все четыре уровня, можно просто сделать то, что фактически будет у вас э ожидаемо от других э ребят.
Так, э, Кирилл, когда крупные изменения сделаны, ADR фиксирует почему-то именно так или не иначе. Какие варианты рассматривались по реализации бортового журнала корабля? Ну, наверное, да. ADR как помогает избежать лишних фич. Ээ, вообще документ полезен, потому что по согласованной архитектуре набирается планирует бюджет. Ну да, я так понимаю, что многие из вас пользуются этим направлением, поэтому здесь, наверное, есть.
Так, Сергей пишет: "Встречал рекомендации, что ADR желательно делать как можно меньше, то есть не раздувать набор фич для проектирования". Ну, смотрите, да, здесь, э, как мы уже рассматривали, конкретно можно зафиксировать те основные решения, потому что вот память архитектора, она достаточно такая часто очищается, да, потому что есть процессы, которые не удерживаешь в голове. И вот именно такие архитектурные заметки, почему именно это решение не иное. Краткость, сестра таланта по-прежнему. Поэтому сделали файлик, написали, положили в папочку Docs в самом проекте. и оно у вас будет существовать. Единственное только возникает вопрос, что его периодически нужно как-то обновлять, и об этом надо не забывать.
А так, ну, собственно говоря, а, друзья, всё остальное, что не успели разобрать вопросов, я думаю, что на основные какие-то вещи я успел, наверное, поотвечать. Всё остальное, если что-то, мм, что не успели задать, то можно написать э мне вконтакте, друзья. Ещё раз спасибо большое за активное участие. Ждём вас на следующих вебинарах и на курсах OTUS. И м желаю вам всего наилучшего.