Системный аналитик (перешла из QA, около 1 года опыта в анализе, уровень между Junior и Middle)
Елена Соколова
Сейчас работаю системным аналитиком в московской финтех-компании. Бэкграунд довольно «смешанный» — сначала три года была тестировщиком, потом внутри компании появилась возможность перейти в анализ, и я ей воспользовалась. В повседневной работе часто приходится обсуждать с архитекторами и разработчиками декомпозицию сервисов и проектирование интерфейсов, но в микросервисной архитектуре у меня долго были только разрозненные представления: какие-то термины знала, а когда нужно было нарисовать диаграмму компонентов или объяснить, почему сервисы делятся именно так, чувствовала себя неуверенно.
Микросервисная архитектура
— На каком курсе учился?
Честно говоря, я не сама искала этот курс. Коллега-старший аналитик порекомендовала курс STENET по микросервисной архитектуре, сказала, что он хорошо помогает «дополнить архитектурный взгляд». Цель была конкретная: не стать архитектором, а научиться в работе аналитика понимать логику архитектурных решений и общаться с архитекторами и разработчиками на одном языке.
Самым полезным был блок по DDD (Domain-Driven Design). Раньше «ограниченные контексты» (bounded contexts) казались чем-то очень абстрактным. На курсе мы прошли весь путь от бизнес-домена до границ сервисов на реальном кейсе, и только тогда я по-настоящему поняла, почему одни сервисы нужно выделять, а другие — нет. Ещё очень понятно объяснили разницу между синхронным и асинхронным взаимодействием (REST vs Kafka). Теперь, когда я рисую диаграммы последовательностей на работе, я сама начинаю думать: «А этому сценарию точно подходит синхронный вызов или лучше событийная модель?»
Цель в целом достигнута. Хотя моя текущая работа пока не требует самостоятельного проектирования микросервисной архитектуры, но теперь на архитектурных ревью я понимаю, о чём идёт речь, и могу задать разумные вопросы со стороны анализа.
Самым полезным был блок по DDD (Domain-Driven Design). Раньше «ограниченные контексты» (bounded contexts) казались чем-то очень абстрактным. На курсе мы прошли весь путь от бизнес-домена до границ сервисов на реальном кейсе, и только тогда я по-настоящему поняла, почему одни сервисы нужно выделять, а другие — нет. Ещё очень понятно объяснили разницу между синхронным и асинхронным взаимодействием (REST vs Kafka). Теперь, когда я рисую диаграммы последовательностей на работе, я сама начинаю думать: «А этому сценарию точно подходит синхронный вызов или лучше событийная модель?»
Цель в целом достигнута. Хотя моя текущая работа пока не требует самостоятельного проектирования микросервисной архитектуры, но теперь на архитектурных ревью я понимаю, о чём идёт речь, и могу задать разумные вопросы со стороны анализа.
— С какой целью приходила на курс? Удалось ли её достичь?
Да, порекомендовала бы, но адресно. Этот курс по микросервисам не подойдёт людям совсем без базы — если вы ещё не знакомы с базовыми понятиями системного анализа (требования, варианты использования, компоненты), на курсе будет тяжело. Он больше для тех, у кого уже есть опыт в анализе или в серверной разработке и кто хочет перейти с уровня «рисую интерфейсы» на уровень «вижу архитектуру».
Темп довольно плотный: за 8 недель разбираются DDD, паттерны коммуникации, управление данными, observability и другие модули, и к каждому есть практическое задание. Преподаватель с реальным опытом архитектуры, и на примерах чувствуется, что он говорит не по учебнику. Записи занятий тоже очень выручают: некоторые темы с первого раза не укладываются, а на втором проходе с конспектом всё становится намного яснее.
Темп довольно плотный: за 8 недель разбираются DDD, паттерны коммуникации, управление данными, observability и другие модули, и к каждому есть практическое задание. Преподаватель с реальным опытом архитектуры, и на примерах чувствуется, что он говорит не по учебнику. Записи занятий тоже очень выручают: некоторые темы с первого раза не укладываются, а на втором проходе с конспектом всё становится намного яснее.
— Посоветуешь ли учиться в нашей школе и почему?