🍏 Что такое компоненты системы и как показать его на схеме архитектуры? 🍏

Компонент — это отдельная, функционально законченная часть системы, которая выполняет определённые задачи и обладает собственным интерфейсом для взаимодействия с другими частями системы или пользователями.

В качестве интерфейсов могут выступать UI (User Interface) или API (Application Programming Interface).

Компоненты системы можно поделить на несколько основных групп:

➕ Frontend / UI - приложения с пользовательским интерфейсом.
> iOS, Android и Web FarmFresh для покупателя (3 отдельных компонента)
> iOS, Android и Web FFFermer для фермеров
> Admin FarmFresh - приложение для администраторов и сотрудников маркетплейса


➕ Backend / API - серверные приложения со своей логикой и API для взаимодействия с ними. Сюда относятся сервисы, микросервисы, API-Gateway и другие компоненты.
> Сервис каталога товаров с его REST API, по которому с ним будут взаимодействовать для получения списка товаров, их поиска
> Сервис платежей с его REST API, по которому с ним будут взаимодействовать сервисы заказов и подписок

➕ БД - базы данных, такие как PostgreSQL, Oracle и ФХ - файловые хранилища.
> БД сервиса каталога с товарами, PostgreSQL
> ФХ для хранения картинок товаров.

➕Системы обмена сообщениями - очереди MQ / брокеры сообщений, такие как RabbitMQ, Kafka и другие.
> Очередь для обработки запросов на рассылку SMS-уведомлений, RabbitMQ


Компоненты выделяют в процессе проектирования архитектуры систем и отражают на схеме архитектуры.


Схема архитектуры может быть визуализирована в:

✔️Геометрические фигуры (прямоугольники, стрелки, облака, своим студентам даю спец. нотацию CR, которую можно использовать в их проектах).
✔️Нотация C4 - идеально, когда нужна чисто техническая архитектура.
✔️Archimate - очень связана с бизнес-контекстом.

Другие нотации моделирования можно посмотреть в этой статье.


В рамках дальнейшей работы над проектом FarmFresh мы будем использовать нотации CR и C4.

#АрхитектураGA #FarmFreshGA

📚 Подборка книг про архитектуру и микросервисы 📚

Когда я только начала знакомиться с архитектурой, то одной из первых и любимых книг сразу стала:

📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс

Благодаря ей я, как системный аналитик, еще раз пересмотрела подходы к проектированию и описанию требований, структурировала знания, и начала осознанно использовать рекомендации из нее.

Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.


В дополнение к ней я бы хотела порекомендовать:

📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!)

📚 Создание микросервисов, Сэм Ньюмен

📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон

📚 Высконагруженные приложения, Мартин Клеппман

📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин

📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа

📚 DDD - предметно ориентированное проектирование, Влад Хононов

Новогодние каникулы скоро, будет время на полезное чтение 🎄

Сохраняйте подборку и делитесь другими крутыми книгами для системных аналитиков в комментариях! 🙂

#АрхитектураGA

☑️✅ Нефункциональные требования: зачем они нужны? ☑️✅

Когда аналитиков знакомят с нефункциональными требованиями (НФТ), то дают примерно следующее:

НФТ — это характеристики системы, которые описывают её качества и ограничения, но не функции и поведение.

НФТ определяют КАК система должна работать, включая производительность, безопасность, масштабируемость, удобство использования и т.д.

Основная цель НФТ — обеспечить определённый уровень качества системы, соответствовать ожиданиям по доступности и скорости работы.

Но никто не объясняет, как потом эти НФТ реализуются в системе. Какие строки кода их обеспечивают!? 👀


Максимум, который для меня был понятен на старте карьеры:
+ наверное, нужны сервера мощнее,
+ персональные данные как-то шифровать будут.
Всё 🥲

Писали их, как мне казалось, для галочки.
Архитекторов у нас не было. Делали монолиты и прекрасно сдавали проекты. Всё работало быстро!

Так что я научилась собирать и описывать НФТ. А вот КАК их реально используют, удалось узнать только на 4-й год в аналитике 😬

Оказалось, если у тебя большой и высоконагруженный IT-продукт, то нефункциональное требование “Должно выдерживать нагрузку до 10 000 пользователей, работающих параллельно” реально что-то значит.

Нефункциональные требования влияют на:

✅ Архитектуру системы:
+ Выделение высоконагруженных функций в сервисы и микросервисы.
+ Использование способов обмена данными между частями системы, которые не будут вызывать промедлений. Например, gRPC API для взаимодействия микросервисов.
+ Выделение конфиденциальных данных в отдельные БД.

✅ Инфраструктуру системы:
+ Запуск нескольких параллельно работающих копий Backend-приложений, БД и ФХ для обеспечения высоких нагрузок.
+ Защита конфиденциальных данных с использованием специального оборудования.
+ Настройка логирования и мониторинга.

Покажу вам примеры в формате:
требование -> влияние на архитектуру!

А пока делюсь подкастом:
🎧 Нефункциональные требования

Статья к этому эпизоду может стать вашим ЧЕК-ЛИСТОМ при разработке НФТ 🤝

#АрхитектураGA

Был такой период, когда было популярно искать своё предназначение — то самое дело, которое будет зажигать и приносить удовольствие. Кажется, это продолжается и сейчас 🤔

Все думают о том, что это связано исключительно с работой. Но а что, если помимо работы, можно реализовываться, и даже достигать каких-то высот, занимаясь любимым хобби?

Конечно, работа на первом месте. Мы стремимся найти её не только как источник хорошего дохода, но и как возможность для самореализации, радости и вдохновения. Это же 40+ из 168 часов в неделю!

Но хобби тоже может стать не менее заметным и значимым способом самореализации 🙌

Хобби — классный способ перезагрузки вне работы.
Оно помогает:
✔️ отвлечься от повседневных забот,
✔️ не думать о рабочих задачах,
✔️ восстановить энергию,
✔️ вдохновиться на что-то новое.

Например, я люблю бегать, рисовать, читать книги и путешествовать.
Нередко, именно когда я читаю или бегаю, мне приходят классные идеи по решению рабочих задач (заметки всегда наготове!) 😏 Это происходит, потому что я расслаблена, отдыхаю, не нервничаю. Короче, нет напряжения.

Если бы в жизни была ТОЛЬКО моя любимая работа, и ни на что другое не оставалось места, то... даже звучит как-то грустно. Жизнь многогранная!

👉 При найме на работу работодатели могут спрашивать про хобби. И это не просто формальность!
Если у вас есть увлечения и жизнь вне работы, это показывает, что вы умеете перезагружаться, держите баланс между работой и личной жизнью.

Хобби - это инструмент защиты от выгорания! 💚🪫🔋

Друзья, только мы сами решаем, как распоряжаться своим временем после работы.
Можно продолжать работать.
Можно лежать и смотреть в потолок.
Можно готовиться к марафону или покупать очередной билет на самолет, чтобы открыть для себя новые места.
Можно всё!
Главное, чтобы это вас перезагружало и заряжало энергией!

Я искренне желаю вам найти то занятие, которое будет вас зажигать, которое будет дарить удовольствие и давать передышку от работы ❤️‍🔥

Делитесь в комментариях, какие у вас хобби? Очень интересно)

🌱 Открыта запись на Архитектуру для системных аналитиков 🌱

Погружение в архитектуру и опыт работы в сложных проектах с микросервисами - точки роста для опытных системных аналитиков уровня Middle+.

Чтобы помогать вам достигать максимального уровня в карьере, мы создали практическую программу “Архитектура систем”.

В ходе работы на ней мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Практиковаться работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks и знакомиться с другими способами асинхронного взаимодействия систем.

Собрали всё, что нужно для проектирования систем на самом глубоком техническом уровне для аналитиков.


Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷

Приглашаем и вас достигать новые цели вместе с нами! 🙌

🌟 Проектирование архитектуры
🗓 Старт предобучения: 3 декабря 2024
👉 Подробности о программе и запись

🎁 До 25 ноября открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.

Все вопросы можно задать через сайт, на почту info@getanalyst.ru или в Telegram @getanalyst.

🔸 Монолит, Сервисная и Микросервисная архитектура - сравнение 🔸

Для системных аналитиков важно не только знать, какие виды архитектур существуют, но и понимать их ключевые отличия и области применения.

В этом посте мы познакомимся с наиболее распространенными видами архитектуры.

🔸 Монолитная архитектура
В монолитной архитектуре все компоненты приложения находятся в одной кодовой базе и работают как единое целое. Это обеспечивает простоту разработки и релизов системы.
Хорошо подходит для стартапов и небольших проектов.

БД:
Обычно используется одна БД, что упрощает взаимодействие между различными частями приложения, но может стать узким местом при масштабировании.
Допустимо несколько БД.

Внутренние интеграции:
Все компоненты взаимодействуют только на уровне кода, интеграции компонентов внутри Backend по API и другими способами не нужны.


🔸 Сервисная архитектура SOA (Service-Oriented Architecture)
SOA разделяет функциональность на отдельные сервисы, которые взаимодействуют между собой через сетевые вызовы - по API, через шину данных (ESB) или другими способами.

Идеально подходит для средних и крупных проектов, где важно обеспечивать высокий уровень доступности или производительности для отдельных частей системы.

Например, в Магазине доставки фермерских продуктов сервис каталога товаров и сервис заказов можно поделить, чтобы инсталлировать на сервере 10 копий сервиса каталога, но всего 3 копии сервиса заказов, т.к. до заказа товаров доходит меньше пользователей чем тех, кто просто смотрит каталог.

БД:
Каждый сервис может использовать свою собственную БД, что облегчает масштабирование и изоляцию сервисов, но также несколько сервисов могут использовать одну БД, что отличает SOA от MSA.

Внутренние интеграции:
Сервисы интегрируются через API, что упрощает интеграцию. Могут использовать шину - ESB.

#АрхитектураGA #FarmFreshGA

Продолжение 👇

🔸 Микросервисная архитектура MSA (Microservice Architecture)
MSA состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет одну бизнес-функцию.

Микросервисы меньше по функциональности чем сервисы. Это обеспечивает высокий уровень масштабируемости и гибкости, но из-за большого количества сервисов такие проекты дорого сопровождать, в частности из-за необходимости опытной и высоко-квалифицированной команды.

Подход эффективен для больших и быстро развивающихся приложений, где требуется быстрая разработка и частые обновления.

БД:
Каждый микросервис в идеале управляет своей собственной БД, что позволяет избежать зависимостей и упрощает масштабирование каждого сервиса по отдельности.

Внутренние интеграции:
Взаимодействие между микросервисами часто строится по API на легких протоколах, таких как REST или gRPC, и может включать очереди и брокеры сообщений для асинхронной коммуникации.



Выбор архитектуры проекта зависит от специфики и требований к системе.
На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

Ключевые подходы к проектированию архитектуры фиксируются в проектной документации. И это не только схемы архитетуры. но и правила, по которым продолжать развивать проект всей команде.

Понимание ключевых аспектов каждого подхода поможет аналитикам определить наиболее подходящую архитектуру для конкретного случая, а также принимать активное и осознанное участие в обсуждениях с разработчиками и архитекторами 🌱

#АрхитектураGA

💚🎁 Analyst Days 19 + GetAnalyst - дарим подарки 🎁💚

Коллеги, на прошлой неделе мы проводили розыгрыш подарков от GetAnalyst (подписка 3мес на БД и SQL) и AnalystDays-19 (билет на конференцию).

Для участия надо было ответить всего на 2 вопроса:
1. Почему вы подписаны на GetAnalyst?
2. Почему вы хотите на конференцию Analyst Days-19?


Подводим итоги:

🟢 Подарили билет Анастасии за её искренний текст про Analyst Days:

Для меня участие в конференции - это новая ступень в моем развитии, как профессионала. И это очень волнительная ступень.

Я почитала заголовки докладов и я в полном восторге) Охватываются и софт и хард скилы. Какие-то доклады обещают погружение в технические детали, а я уже предварительно моделирую, где и как можно применить полученные знания.

С GetAnalyst было сложно…
В следующий раз буду с генератором случайных чисел розыгрыши делать 😅 Поэтому подарков дали чуть больше.

Два самых отложившихся в сердце ответа:

🟣 Кристина

Это как напоминание, что «чем больше я знаю, тем больше понимаю что ничего не знаю».

Канал помогает мне структурировать свои знания и выявлять пробелы. Ловлю классные инсайты на основе прочитанного для решения своих рабочих задач. Узнаю про новые инструменты, выполняю дополнительные практики чтобы не стагнироваться.

У меня на проекте уже второй стажер и статьи помогают мне выстраивать их трек развития.

🟣И еще одна Кристина 😊

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

После недлительного наблюдение за каналом, решила приобрести курс по архитектуре. Осталась им более чем довольна

Продолжаю следить за обновлением в паблике, потому что нахожу массу полезного контента, ориентированного на прикладное применение

+ мы дали еще больше подарков от GetAnalyst.


🎁 Полные тексты и результаты на сайте.


Коллеги, спасибо вам за эти ответы! 🩷

Я стараюсь сделать всё возможное, чтобы GetAnalyst был источником ваших знаний и вдохновения.


Искренне ваши,
Екатерина Ананьева
и команда GetAnalyst!

📚 Как выделять микросервисы? 📚

1️⃣ По группам функций
2️⃣ По доменам (Domain-driven Design, DDD)
3️⃣ По данным
4️⃣ По пользовательским сценариям
5️⃣ По уровню нагрузки

Подходы могут использоваться как комбинированно, так и отдельно. Каждый эффективен по-своему.

А подробнее и с примерами рассказала о них в мини-книге, прикрепленной к посту.

Сохраняем в личную библиотеку книг от GetAnalyst 💜

#АрхитектураGA #FarmFreshGA

🧐 Должны ли аналитики заниматься проектированием архитектуры? 🧐

Начну с того, что есть другие профессии для этого:

✅ Systems Architect (Системный архитектор) - проектирует техническую архитектуру отдельных систем. Фокусируется на взаимодействии компонентов, структуре кода и выборе технологий реализации. Работает с кодом.

✅ Enterprise Architect (Корпоративный архитектор) - создаёт стратегию для всей ИТ-инфраструктуры компании, обеспечивая её соответствие бизнес-целям и интеграцию всех систем. Работает на уровне организации, задавая стандарты и политики. Не всегда работает с кодом.

✅ Solutions Architect (Архитектор решений) - отвечает за архитектуру решений, в которую входит сбор требований к проекту, поиск лучших технических решений, описание структуры и поведения ПО, распределение задач на разработчиков и многое другое. Не всегда работает с кодом.

✅ Лиды разработки, которые выполняют роль любого из архитекторов.

Эти роли часто пересекаются, но их подход к масштабам и фокусу на проектировании различается.
Согласитесь, схожая ситуация с БА и СА.


В последние годы я всё чаще встречаю вакансии Solutions Architect на hh.ru и других ресурсах для поиска работы, где требования к кандидату содержат строку в формате:

Кого мы ждём?

Если вы опытный разработчик или системный аналитик, то откликайтесь скорее!

Также компании стараются выращивать своих Solutions Architect из опытных Системных аналитиков, которые и так уже проектируют и документируют архитектуру:
✔️ вместе с лидами разработки,
✔️ вместе с архитекторами,
✔️ самостоятельно.

Очень выгодно и удобно иметь в штате Senior Системного Аналитика, который может работать с архитектурой.


Так как Системный аналитик находится на стыке бизнеса и разработки, то он лучше всех разбирается в логике проекта и может делить функциональность на логические составляющие. А при знании технологий - не специалист, а бриллиант! 💎

ЗП у таких аналитиков, как правило, на уровне архитекторов.


И чтобы выращивать таких крутых Системных аналитиков, нас подключают в техническое проектирование по полной программе:

1. Ходим на встречи с архитекторами/разработчиками по обсуждению архитектуры.

2. Копаемся в коде, чтобы понять “а как это вообще работает”.

3. Берем на себя задачи по анализу и подбору технологий, чтобы принести в команду структурированные доки по результатам исследований.

4. Проектируем API, описываем технические требования к интеграции систем, проектируем БД.

5. Анализируем логи, смотрим на дашборды мониторинга системы.

6. Рисуем архитектурные и инфраструктурные схемы после встреч по архитектуре (а кто же еще документацию сделает, если не аналитик? 🥲).

7. Много читаем и учимся.

8. Много всего 🙂

Должен ли аналитик заниматься проектированием архитектуры?

Выделять микросервисы, рисовать архитектуру, выбирать API для взаимодействия между сервисами…

Нет.

Официально мы можем остановиться в развитии, когда научились техническому проектированию и постановке задач на разработчиков:
+ сбор и анализ требований,
+ описание сценариев Use Case,
+ проектирование БД,
+ описание интеграций,
+ разработка требований к структуре API-методов,
+ ведение документации.

Но зачем останавливаться на достигнутом, если можно быть любопытным и есть куда расти? 🚀💎

Поэтому, коллеги, выбор всегда за вами. Принимать на себя новую ответственность и знания, когда вас зовут на встречу по архитектуре, либо сказать "это не моя зона ответственности" и идти решать свои задачи.

А какое у вас мнение по поводу работы аналитиков с архитектурой? Сталкиваетесь ли с ней сейчас в работе?
Поделитесь в комментариях 🙏

#АрхитектураGA