Speaker A
Угу. Так, а получается, CASE, системный аналитик не пишет. А был ли у тебя вообще такой опыт? Ну, скажем так, фулстек-аналитика не выделяют вот такого системного?
Интервью-разбор собеседования на системного аналитика: CASE-инструменты, секвенс-диаграммы, Kafka vs RabbitMQ, распил монолита на микросервисы и роль BFF и гейтов. Опыт кандидата в Самокате.
Key Takeaways
- Системный аналитик должен уметь выбирать между синхронным и асинхронным взаимодействием и понимать, когда нужны брокеры сообщений.
- Гибкость в нотациях важнее формального соответствия стандарту, если это улучшает понимание разработчиками.
- Выбор Kafka или RabbitMQ зависит от модели доставки, требований к нагрузке и необходимости хранения сообщений.
- Распил на микросервисы требует пересмотра контрактов и продуманных границ доменов.
What the video covers
- Обсуждение разницы между системным и бизнес-аналитиком и предпочтений кандидата: ему ближе чисто системная часть без юзкейсов.
- Рассказ о работе с секвенс-диаграммами и способах отображения синхронных и асинхронных запросов по нотации.
- Кандидат признаёт, что строгое следование нотации не всегда оправдано, и часто проще нарисовать обычную стрелку с отдельным актором, например для Kafka-топика.
- Использование ER-диаграмм и UML-диаграмм классов на логическом и физическом уровнях, с ключами, типами данных и обязательностью полей.
- Сравнение брокеров сообщений: RabbitMQ (push-модель, умный продюсер) и Kafka (pull-модель, умный консьюмер, хранение сообщений, высокие нагрузки), опыт работы в Самокате с Kafka.
- Опыт проектирования продукта с нуля: проектирование базы и архитектуры, участие в архитектурных драфтах.
- Распил монолита на четыре микросервиса по доменным границам ещё до первого релиза, с переписыванием контрактов и добавлением backend-to-backend методов.
- Объяснение паттернов API-гейтов: external и internal гейты для изоляции внешних интеграций и BFF для межпродуктовых сценариев и разных клиентов (веб, мобильные приложения).
- Упоминание DDD, CQRS, Event Sourcing и Transactional Outbox как архитектурных паттернов.
- Интервью проходит в формате неформального разговора с техническими вопросами.
Chapters
- 00:00Вступление: роль системного аналитика и опыт кандидата
- 01:05Системная часть vs бизнес-аналитика: предпочтения
- 02:53Секвенс-диаграммы и синхронные/асинхронные запросы
- 04:56ER и UML-диаграммы: уровни проектирования
- 07:43Проектирование архитектуры продукта с нуля
- 09:49Распил на микросервисы и контракты
- 10:57Гейты, BFF и архитектурные паттерны
Full Transcript — Download SRT & Markdown
Speaker A
То есть Угу. Не, а как тебе больше нравится? Просто когда ты в фустек идёшь, э, условно, там, начиная от бизнесовой вообще потребности всё это разбираешь или когда тебе принесли юзкейс и ты там базы может тебе нравится проектировать, я не знаю.
Speaker A
Да. Да, конечно, был, но не в Самокате, а на предыдущих проектах, да.
Speaker A
Вот. А с точки зрения, наверное, именно своей работы, м больше нравится, конечно, заниматься чисто системной частью, да, то есть без юзкейсов. Вот был проект, на котором я сначала писал юзкейс, а по, ну, типа, примерял на себя шапочку бизнес аналитика, да, а потом
Speaker A
То есть угу. Не, а как тебе больше нравится? Просто когда ты в фулстек идёшь, условно, там, начиная от бизнесовой потребности, всё это разбираешь, или когда тебе принесли юзкейс и ты там базу, может, тебе нравится проектировать, я не знаю?
Speaker A
Угу. Так. Аа seквенс диаграммы, вы получаете часто их используете. А скажи, пожалуйста, аа как на секвенсе можно отобразить синхронный это или асинхронный запрос?
Speaker A
Ну, базу мне нравится, да, проектировать. Но да, тут смотри: в любом случае я всегда стараюсь в первую очередь для себя понять, да, бизнес, как бы ценность, смысл того, что мы делаем.
Speaker A
Но, честно говоря, э я в какой-то момент понял то, что полное точное, что ли, следование аннотации - это далеко не всегда блага.
Speaker A
Вот. А с точки зрения, наверное, именно своей работы, м, больше нравится, конечно, заниматься чисто системной частью, да, то есть без юзкейсов. Вот был проект, на котором я сначала писал юзкейс, а по, ну, типа, примерял на себя шапочку бизнес-аналитика, да, а потом снимал её, заменял на шапочку системного аналитика, брал свой юзкейс и шёл дальше его расписывать. Это, конечно, было забавно, но время достаточно много занимало.
Speaker A
Поэтому проще, может, нарисовать обычную стрелку, не заморачиваться и просто отдельным актором вывести то, что вот это кавка топик, да, вот сюда приходит стрелка, и мы там вот этот сервис-продюсер туда записывает, а вот этот оттуда потребляет. И так будет
Speaker A
Угу. Так. А, секвенс-диаграммы вы получаете часто, их используете? А скажи, пожалуйста, а как на секвенсе можно отобразить синхронный или асинхронный запрос?
Speaker A
такой. А, да, да, где-то совсем давно сталкивался с Рэбетом, но последние, ну, последние года в основном кавка, вот в самокате именно кавка используется. Вот с MQP, MQTT, ну, скорее слышал, но не сталкивался.
Speaker A
Мм, для асинхрона, по-моему, там же пунктирная линия рисуется, и стрелка вроде не сплошная, но это если по канону, да, по-моему, примерно так вот.
Speaker A
тупой брокер и умный консюмер, да, у Ребита наоборот тупой консюмер и умный продюсер получается.
Speaker A
Но, честно говоря, я в какой-то момент понял, что полное, точное, что ли, следование нотации — это далеко не всегда благо.
Speaker A
хранит что-то, поэтому для некоторых именно она подходит. Так, что ещё? Что ещё интересно? А, диаграммы получается класс. Ну, ты сказала ER диаграммы это были вот UML-диаграммы, просто диаграммы классов, типа на логическом, на физическом уровне, на каком-то проектировании просто
Speaker A
Почему? Потому что кроме тебя в команде больше, может, никто и не знает эту нотацию, ну вот прямо так досконально.
Speaker A
А, ну, в ряде случаев с индексами, да? То есть тут Ну, да, да. Угу.
Speaker A
Поэтому проще, может, нарисовать обычную стрелку, не заморачиваться и просто отдельным актором вывести то, что вот это Кафка-топик, да? Вот сюда приходит стрелка, и мы там вот этот сервис-продюсер туда записывает, а вот этот оттуда потребляет. И так будет гораздо понятнее, чем если ты нарисуешь какую-то другую стрелку, а потом к тебе разраб придёт и скажет, что он вообще может даже не заметить стрелки, я ничего не понял, да, не сделал, да? Да, конечно. Вот такое. Брокерами сообщений тебе приходилось работать, был такой опыт?
Speaker A
Принимал ли ты в этом участие вообще в целом в планировании архитектуры там из Legy, допустим, а перевоз на микросервисы? Какой-нибудь такой опыт был?
Speaker A
А, да, да, где-то совсем давно сталкивался с RabbitMQ, но последние года в основном Кафка, вот в Самокате именно Кафка используется. Вот с MQP, MQTT ну, скорее слышал, но не сталкивался.
Speaker A
Ну первый драфт, по-моему, архитектор. Дальше уже, э, значит, я принимал участие в проектировании архитектуры продукта. А касательно распила на микросервисы было забавно в том плане, что мы распилились действительно микросервиса, но ещё до того, как вообще был хоть какой-либо
Speaker A
Угу. Рэбит или Кафка? Вот какие-нибудь самые значимые отличия между ними сможешь рассказать?
Speaker A
на база, да, и ты можешь до любой таблицы дотянуться. Аа, но потом, значит, э решили, что пусть чуть-чуть сначала будет посложнее, но зато потом мы получим бенефиты от этого распила. И вот на бумаге ещё до даже самого первого
Speaker A
Ну, у них отличаются модели, да? То есть у Рэбита пуш-модель, у Кафки пул-модель. То есть, соответственно, у Кафки это не то чтобы тупой продюсер, скорее тупой брокер и умный консюмер, да? У Рэбита наоборот, получается, тупой консюмер и умный продюсер.
Speaker A
несущественный одинаковый несущественный. Вот. И а контракты, соответственно, пришлось тоже переписать, плюс добавить некоторые, э, чисто, ну, backend to backend.
Speaker A
Вот. А, ну и Кафка с точки зрения самой себя гораздо больше нагрузки, более высокие нагрузки может выдерживать. То есть это нагружённую систему использовать, притом, да, дороже стоит, но у Кафки есть огромный плюс: она у себя, да, хранит что-то, поэтому для некоторых именно она подходит.
Speaker A
Угу. Ну, то есть вы распиливали и исходя из вообще вот, ну, условно DDD, да, домены у вас управляли тем, какие сервисы будут, а, созданы. А в целом м архитектурные какие-нибудь паттерны проектирования, вот ты знаешь, знаком с ними?
Speaker A
Так, что ещё? Что ещё интересно? А, диаграммы получаются класс. Ну, ты сказала, ER-диаграммы — это были вот UML-диаграммы, просто диаграммы классов, типа на логическом, на физическом уровне, на каком-то проектировании, просто на физическом, то есть с промежуточными таблицами, да, с ключами, с типами данных, с обязательностью.
Speaker A
И в то же время, чтобы мы могли достаточно легко менять подрядчиков, так как контракты самого гита остаются теми же самыми. Ну, соответственно, для каких-то наших внутренних походов межпродуктовых в рамках ландшафта всей компании. Вот это BFF.
Speaker A
А, ну, в ряде случаев с индексами, да? То есть тут ну, да, да. Угу.
Speaker A
Вот. И особенно, если ими занимаются разные команды, чтобы, ну, каждая команда могла как бы вести свою разработку независимо друг от друга. Вот это те же там SEQS, SGA, Event Sourcing, там Transactional Unbox, например. Вот. Ну, ну вот, наверное, в первое, что в голову
Speaker A
Так, окей. Что ещё такого? А вот архитектура, м, то, как она у вас сейчас представлена, и то, как вы делаете, это тоже исторически сложилось или вы вместе это как-то проектировали?
Speaker A
будешь принимать решение синхронно, тут асинхронно и вообще, может быть, нам брокеры нужны, как бы на что будешь опираться?
Speaker A
Принимал ли ты в этом участие вообще, в целом, в планировании архитектуры, там, из монолита, допустим, на микросервисы? Какой-нибудь такой опыт был?
Speaker A
ряде только случаев, наверное, мы можем наколить и засунуть там два топика, один условно для запросов, другой для ответов. Вот. Но это для этого должны быть достаточно везкие причины. Вот.
Speaker A
Ну тут смотри, конкретно с этим продуктом я участвовал с самого нуля. То есть когда его вообще не было, я полностью спроектировал всю базу для продукта, архитектуру проектировал. Ну, первый драфт, по-моему, архитектор. Дальше уже я принимал участие в проектировании архитектуры продукта.
Speaker A
или на самом деле может асинхронный рест можешь, да, применить и там заиспользовать какой-нибудь полинг, например, да, или там север events, например. Ну то есть тут опять же в зависимости от тех стек, да, может там вебсокеты вообще больше подойдут,
Speaker A
А касательно распила на микросервисы было забавно в том плане, что мы распилились действительно на микросервисы, но ещё до того, как вообще был хоть какой-либо продукт реализован. То есть по факту мы распиливались просто на бумаге, да. Мы сначала всё спроектировали, описали, и баз данных, и, ну, единственное, там со всеми связями, и API-контракты описаны с учётом того, что у тебя одна база, да, и ты можешь до любой таблицы дотянуться.
Speaker A
Вот к плюсу можно отнести то, что у тебя, значит, размазывается более-менее ровным слоем нагрузка и на как бы сервис отправителя, на сервисполучатель, да, то, что если тебе нужно отправить информацию там сразу в три, допустим, других сервиса, тебе не нужно делать три
Speaker A
Но потом, значит, решили, что пусть чуть-чуть сначала будет посложнее, но зато потом мы получим бенефиты от этого распила. И вот на бумаге, ещё до даже самого первого релиза, немножечко перепроектировали базу, там лишние ключи снесли, да, распилились на четыре сервиса, по-моему, ну, чисто по доменам, да, то есть по каким-то смысловым границам, потому что профиль нагрузки там, в принципе, на каждый из них был одинаковый. Ну, несущественно одинаковый. Вот. И контракты, соответственно, пришлось тоже переписать, плюс добавить некоторые, чисто, ну, backend-to-backend методы, внутрянские, внутренние, в смысле, извини, которые, условно, ты обращаешься к сервису А, сервис А идёт к сервису Б, что-то там дотягивает, компонует и возвращает для таких сценариев. Вот.
Speaker A
твой как бы корневой корсервис, он продолжает работать и не сильно зависит. И, в принципе, сценарий даже может там как-то процент на семьдесяты выполниться. Вот, э, на получателе опять же то, что если получатель вычитывает сразу несколько топиков, да, ему не
Speaker A
Угу. Ну, то есть вы распиливали, исходя из, вот, условно, DDD, да, домены у вас управляли тем, какие сервисы будут созданы. А в целом, м, архитектурные какие-нибудь паттерны проектирования, вот ты знаешь, знаком с ними?
Speaker A
плюсам. Из минусов, э, ну, во-первых, то, что я сказал про отказоустойчивость, это с одной стороны, да. С другой стороны, если представлять, э, значит, архитектуру всей системы, тот же брокер - это ещё один кубик, да, это ещё одна точка отказа. Аэ
Speaker A
Да, ну, в принципе, те же гейты, про которые ты говорила, да, то, что мы применяем, external и internal гейты. Ну, external, соответственно, при интеграции с какими-то внешними подрядчиками, системами, чтобы наша внутренняя логика какая-то наружу не торчала. И в то же время, чтобы мы могли достаточно легко менять подрядчиков, так как контракты самого гейта остаются теми же самыми. Ну, соответственно, для каких-то наших внутренних походов межпродуктовых, в рамках ландшафта всей компании, вот это BFF. Туда же можно отнести, в принципе, это те же гейты, да, для разных клиентов, если у нас есть веб, мобилка, например. Вот. И особенно, если ими занимаются разные команды, чтобы каждая команда могла вести свою разработку независимо друг от друга.
Speaker A
же external гитами. А это то, что банально сложнее тестировать интеграцию, да? То есть, если у нас синхронщина, то там открыл постман свагер, да, потыкал, всё как бы понятно. Вот в случае с теми же кавка-топиками, а, ну, есть, конечно,
Speaker A
Вот это те же там CQRS, SAGA, Event Sourcing, там Transactional Outbox, например. Вот. Ну, наверное, первое, что в голову пришло.
Speaker A
проверить - это зайти в сервис, допустим, в базу сервиса консюмера и посмотреть, там вообще данные появились или нет. Вот. Ну и чисто с организационной точки зрения это то, что у тебя должны быть в команде люди, которые умеют вообще как бы готовить,
Speaker A
Так, окей. А вот при планировании архитектуры, допустим, если ты будешь делать это совместно, там, вот с разработчиком, тимлидом, архитектором, неважно, я имею в виду не enterprise-архитектуру, а вот уже solution для наших сервисов, а на основании чего будешь принимать решение: синхронно тут, асинхронно, и вообще, может быть, нам брокеры нужны? Как бы на что будешь опираться?
Speaker A
Ну вот, наверное, как-то так. Так, я поняла, спасибо. Что у меня, наверное, ещё по вопросам будет. А я не знаю, я так поняла, на этом проекте у тебя сейчас аналитик всё-таки делает сначала вот работу и полную постановку и продумывает
Speaker A
Ну, в первую очередь от самой задачи, да? То есть если от пользовательского сценария, если по сценарию мы должны получить результат нашего действия, нашего запроса какого-то прямо здесь и сейчас, то, очевидно, что это должен быть синхронный поход. В ряде только случаев, наверное, мы можем наколхозить и засунуть там два топика, один условно для запросов, другой для ответов. Вот. Но для этого должны быть достаточно веские причины.
Speaker A
взаимодействуют и взаимодействуют с другими. У нас очень много интеграции, и у нас в целом система построено на том, что мы постоянно с кем-то интегрируемся, нам с кем-то приходится договариваться и менять свои подходы в зависимости от того, мм, какой у нас там поставщик
Speaker A
Если же, соответственно, обратная ситуация, да, и тебе не обязательно прямо здесь и сейчас, то есть ты можешь отправить запрос и пойти дальше гулять, какие-то дальше запросы выполнять, то можно асинхронщину применить и, в частности, рассмотреть брокеры. Ну или на самом деле можно асинхронный REST применить и там использовать какой-нибудь polling, например, или там Server-Sent Events, например. То есть тут опять же в зависимости от техстека, может, там WebSocket вообще больше подойдёт, если какая-нибудь направленная связь нам нужна. Вот. А в остальном, ну, есть как бы свои плюсы, свои минусы, да, у применения тех же брокеров по сравнению
Speaker A
решение и совместно его вырабатывают, совместно декомпозируют задачу, исходя из того, как это будет, возможно, даже удобнее э реализовывать там ребятам, я не знаю, можно сделать целую какую-то историю, а можно поделить? Они говорят: "Нет, мы этот сервис там будем сейчас
Speaker A
там два спринта пилить, зато он потом будет везде участвовать. Вообще это оркестратор и суперу удобно". Поэтому нам нужно сделать его сейчас. Поэтому разбери его, пожалуйста, сейчас помоги нам. Или вот ээ тебе больше нравится подход, когда аналитик такой, это царь и
Speaker A
бог, который сказал такой: "Смотрите, делаем так и никак иначе и вообще слушайте меня". Ну нет, слушай, всё-таки не совсем, ну, царь и бог, да, потому что в любом случае аналитик никогда не может знать ээ то, как лучше будет сделать лучше, чем разработчик,
Speaker A
потому что аналитик не кодит. Вот. А-э, в любом случае, даже, ну, в нашей команде, аэ, да, я там, допустим, что-то описываю, что-то проектирую, но в конечном счёте, в любом случае это ну, опровлю, да, то есть показываю прежде перед разработкой тамду,
Speaker A
например, да, говорю: "Вот толь там посмотри, всё ли тут о'кей, всё ли тебя с этим норм". Вот. И, ну, иногда, естественно, бывает какой-то диалог, да, и мы какой-то компромисс, допустим, находим. Там или Тимлит объясняет, почему ему кажется, что будет лучше по,
Speaker A
ну, а сделать зада Ну да, по-другому. Или наоборот у меня хватает там, допустим, бизнесовой какой-то аргументации, что нужно сделать именно так. То есть тут, естественно, это всегда должен быть какой-то диалог, поэтому нет, скорее первый подход, конечно, ближе.
Speaker A
из тех, которые ты упомянул, что, ну, повторюсь, аналитик не может, да, на 100% знать лучше, чем разраб Угу.
Topics:системный аналитиксобеседованиеKafkaRabbitMQмикросервисысеквенс-диаграммыAPI gatewayBFFDDDархитектура
