GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

🔥 13 ошибок в использовании BPMN: разбор на примере задачи 🔥

В этом эпизоде подкаста мы разбираем 13 типичных ошибок при использовании нотации BPMN на примере задачи, которую может получить на собеседовании Системный или Бизнес-аналитик.

🔗 Презентация и полезные ссылки

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

Эпизод будет полезен как начинающим, так и опытным аналитикам, стремящимся улучшить свои навыки в создании BPMN-диаграмм для описания бизнес-процессов.

Видео эпизода доступно в:
⏯ RuTube
⏯ YouTube
⏯ VK Video

Аудио-эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Spotify

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

🧐 Как системный аналитик влияет на проектирование архитектуры 🧐

Проектирование архитектуры систем вместе с разработчиками и архитекторами — одна из больших задач системного аналитика.

В этом процессе аналитик становится мостиком между бизнес-процессами и техническими решениями. Понимать надо глубоко и то, и другое.

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

1. Исследования и анализ
2. Выбор подхода к проектированию архитектуры
3. Формирование концептуальной схемы архитектуры
4. Оценка влияния нефункциональных требований

🔗 Ссылка на статью

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

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

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

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

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

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

💥 Разбор спорных вопросов по REST API с проектов и собеседований: исследуем Trello и Todoist 💥

Как понять, что мы проектируем REST API правильно? Никак. Смотреть на публичную API‑документацию крупных систем, диссертацию Роя Филдинга, или на то, что уже есть в проекте. И исходя из этого принимать решения о том, как будут выглядеть новые REST API методы.

В этой статье я хочу представить результаты исследований REST API сервисов управления задачами Trello и Todoist, чтобы показать, какие решения являются хорошими стандартами проектирования, а какие нет, но их всё равно применяют на практике.


👉 Решенные вопросы с обоснованием ответов:

1. Какой HTTP-код ответа на метод POST: 200 или 201?

2. Какой метод лучше использовать для редактирования данных: POST, PUT или PATCH?

3. Как правильно строить структуру URL запросов (эндпоинтов)?

4. Как правильно именовать эндпоинты — ед. число или мн. число (/task или /tasks)?

5. Как строить эндпоинт и body в REST API методе, если нам нужно создать задачу, и она должна быть создана внутри проекта?

6. Что вернуть в ответ на запрос списка, если ничего не найдено — пустой массив или HTTP-404?

7. Какой код вернуть в ответ на запрос DELETE?

8. Может ли быть у DELETE тело запроса?

9. Чем отличается REST от RESTful API?


🔗 Ссылка на статью


На примерах из этой статьи можно отстаивать свою правоту на собеседованиях и для команды, при проектировании методов REST API 💪

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

🔵 C4 / Context - разбор на примере 🔵

Уровень Context в нотации C4 используется, чтобы дать высокоуровневое представление о системе и ее окружении.

Он помогает понять что делает система, какие пользователи с ней взаимодействует, какие другие системы с ней связаны - интеграции.

Схема легко читается как бизнес-владельцами продукта, так и разработчиками.


👉 Что нужно показывать?

🔹 Основную систему – объект проектирования (например, интернет-магазин, банковское приложение).

🔹 Пользователей – кто взаимодействует с системой (клиенты, администраторы, партнеры).

🔹 Другие системы – с чем интегрируется (платежные сервисы, справочники, ЭДО и другие системы).

🔹 Типы взаимодействий – основные потоки данных (например, клиент отправляет заказ в систему, система взаимодействует с банком).


👉 Что важно знать?

На этом уровне НЕ важно, какая архитектура будет использована – монолит, микросервисы, сервисы.

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

Это первый шаг проектирования архитектуры – помогает всем участникам проекта построить общее понимание системы.


👉 Пример для системы бронирования жилья - проект #BookingGA

✔️ Основная система:
BookingGA

✔️ Пользователи:
владельцы жилья,
арендаторы,
сотрудники тех поддержки,
администраторы платформы

✔️ Внешние системы:
платежная система РайфПэй (Интернет-эквайринг),
сервис parser-api для проверки паспортов
сервис reestrnet для проверки документов на жильё


Схема архитектуры в C4/Context по проекту прикреплена к посту 🙌


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

🔷 Нотация С4 для документирования архитектуры 🔷

Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично!

Но иногда автора схемы можно понять по-разному. И могут быть вопросы как её развивать дальше.

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


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

👉 Контекст (C4 / Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние
✔️ Пользователи

👩‍💻 Полезна бизнес- и техническим специалистам


👉 Контейнеры (C4 / Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.

👩‍💻 Полезна архитекторам, разработчикам и системным аналитикам.


👉 Компоненты (C4 / Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.


👉 Код (C4 / Code)
На этом уровне детализируют каждый компонент c C4 / Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.


Материалы:
🔗 Официальный сайт C4
🔗 Пример архитектуры C4 в Miro
🔗 Нотация С4 — примеры диаграмм и инструменты

Основные инструменты:
🔗 Draw.io
🔗 Structurizr


Элементы нотации с пояснениями в картинках к посту.

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

💚 Swagger - Open API - Практическое руководство. Часть 3 💚

Ранее опубликовано:
🔗 Часть 1. Регистрация аккаунта и создание демо-проекта
🔗 Часть 2. Создание собственного проекта и работа с базовыми настройками, первые строки кода

В этом посте:
👉 Часть 3. Описание методов POST и GET по спецификации OpenAPI
файл прикреплен к посту

Что внутри:
✔️ Разберетесь с блоками кода paths и components в OpenAPI
✔️ Получите готовый документ API-документации для личного портфолио с двумя описанными методами
✔️ Получите реальный опыт работы со Swagger / OpenAPI

⏳ Время на изучение и практику:
🕓 60 минут — на работу с заданиями строго по руководству, где есть подсказки по каждому шагу
🕓 +60 минут, если хотите выполнить ДЗ и создать личный демо-проект для портфолио


Пост не просто для сохранения, а для реального улучшения вашего технического опыта работы! 🙌

#RestApiGA

🔥 Практическая программа по Архитектуре для СА стартует 4 марта: открыли предзапись 🔥

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

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

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

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


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


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

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


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

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

🏠 Новый проект: микросервисная архитектура для платформы аренды недвижимости #BookingGA 🏠

Теорию надо закреплять на практике. Только так реально разобраться во всей сложной

👉 В этом месяце мы проектируем архитектуру для проекта BookingGA.

Покажу вам три варианта реализации архитектуры:
+ Монолит
+ SOA
+ MSA


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

Основные функции платформы:
✔️ Поиск недвижимости для аренды.
✔️ Бронирование жилья — моментальное подтверждение или с подтверждением владельцем после бронирования.
✔️ Электронный договор аренды — автоматическая генерация сразу после оплаты, электронное подписание обеими сторонами и хранение документов в PDF.
✔️ Безопасные платежи — интеграция с платёжными системами, депозиты, автоматическое списание средств за аренду.
✔️ Верификация владельцев и арендаторов — проверка документов, права собственности.
✔️ Отзывы и рейтинги — оценки арендаторов и хозяев, история аренд.
✔️ Управление объявлениями — возможность владельцев редактировать, деактивировать, продвигать объявления.
✔️ Поддержка пользователей — чат с техподдержкой, система обращений.

Для пользователей будут разработаны приложения на iOS, Android и Web. Владельцы смогут управлять объектами через веб-приложение. Панель администратора поможет тех. поддержке и администраторам модерировать систему.


План работы:
0️⃣ Расскажу про нотацию C4
1️⃣ Покажу архитектуру монолита в нотации C4
2️⃣ Научу выделять сервисы и микросервисы
3️⃣ Покажу архитекту SOA и MSA в нотации C4
4️⃣ Выберем технологии для обмена данными — REST API, gRPC, GraphQL и другие
5️⃣ Посмотрим когда и зачем нужны брокеры Kafka и RabbitMQ, встроим в архитектуру


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

Стартуем отсюда, и следим за постами с хэштегом #BookingGA! 🙂

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

📄 Про собеседования, резюме и вилки ЗП 📄

Проходить собеседования - тоже навык, и его надо оттачивать.

Но эту тему я почти не поднимаю в канале, так как я больше "суровый технарь", который передаёт технические навыки и опыт работы 😁

А чтобы всегда быть в курсе, как пройти через HR на техническое собеседование и самопрезентовать себя, понимать, как менять карьеру и тактично спрашивать о большей ЗП.

Я рекомендую посмотреть подборку материалов, не моего авторства, по резюме, собеседованиям и оценке своей ЗП:

🔴Ключевые лайфхаки по резюме и его ОШИБКИ
🔴Нужны ли сопроводительные и что там писать
🔴Как отвечать на вопрос «Расскажите о себе»
🔴Как вести себя с неадекватом на собесе
🔴Как рассказывать о своем факапе?
🔴Какие книги почитать в т.ч. для успешного прохождения собеседований?
🔴Реальные примеры офферов бизнес и системным аналитиков до 500к

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

✨ Монолит ⚔ Сервисы (SOA) ⚔ Микросервисы (MSA) ✨


👉 Архитектура

◽️ Монолит:
Один большой блок - единая кодовая база Backend.
Вся логика в одном месте.

🟡 SOA:
Отдельные сервисы с независимыми кодовыми базами.
Логика распределена.
В SOA сервисы крупные и многофункциональные, их можно назвать "микромонолитами".

💚 MSA:
Небольшие, автономные сервисы, каждый из которых отвечает за управление одной сущностью, процессом или задачей.
В MSA сервисы более узкоспециализированные по сравнению с SOA.

Сравнение сервисов в SOA и MSA на примерах:

🔹 Каталог товаров
SOA:
+ Сервис "Каталог" – управляет товарами, категориями, характеристиками, поиском и рекомендациями.
MSA:
+ Сервис управления товарами – добавляет, редактирует, удаляет товары
+ Сервис поиска – отвечает только за фильтрацию, поиск и выдачу результатов
+ Сервис рекомендаций – анализирует покупки пользователей и предлагает похожие товары

🔹 Корзина покупок
SOA:
+ Сервис "Корзина" – хранит товары пользователя, управляет ценами и скидками
MSA:
+ Сервис корзины – добавляет и удаляет товары.
+ Сервис расчёта цен – отдельно высчитывает итоговую сумму с учётом акций, налогов и доставки
+ Сервис промокодов и скидок – управляет купонами, скидками, программами лояльности



------------------

👉 База данных

◽️ Монолит:
Обычно одна на всю систему, но может быть и больше.

🟡 SOA:
Сервисы могут иметь общую БД или отдельные схемы внутри одной БД.

💚 MSA:
У каждого микросервиса своя БД.

Сравнение SOA и MSA:
Например, обновление платежного модуля в интернет-магазине с MSA не затронет каталог товаров, так как у них разные БД. В то время как в SOA архитектуре могут быть проблемы с обновлениями из-за наличия общей БД.



------------------

👉 Независимость, масштабируемость и отказоустойчивость

◽️ Монолит:
Если отказывает что-то в монолите, то он ломается целиком.
Релиз обновлений приводит к полной недоступности всего Backend.
Сложно масштабировать:
- постоянно надо добавлять новые мощности (память, ядра и другие) к существующему серверу при добавлении новых функций,
- если запущено несколько параллельно работающих копий монолита, то при росте пользователя, надо запускать новую дорогую копию.


🟡 SOA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса. Но могут быть сложности с отключением нескольких сервисов, когда выполняются обновления общих БД.
Можно масштабировать каждую БД и сервис по мере необходимости - т.е. если растет нагрузка на каталог товаров, то запустим больше копий только этого сервиса, а не всей системы.


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



------------------

👉 Взаимодействие

◽️ Монолит:
+ внутреннее, через вызов процедур и функций в одном коде.


🟡💚 SOA и MSA:
+ напрямую по API (REST, gRPC и другие),
+ через шину данных ESB,
+ через API-сервисы, в том числе можно использовать API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.



------------------

Когда лучше монолит, когда SOA, а когда MSA?

Когда монолит?
✅ Если у вас стартап и ограниченный бюджет.
✅ Нет опытных специалистов и архитекторов, кто работал с MSA.
✅ Нужно сделать быстро и протестировать гипотезу.
✅ Нет высокой нагрузки – мало пользователей.

Когда SOA?
✅ Большая корпоративная система с интеграциями.
✅ Если в компании уже используется ESB.
✅ Не требуется высокая скорость изменений – SOA сложнее менять, так как сервисы могут зависеть от общей БД или централизованных решений.

Когда MSA?
✅ Нужна высокая скорость изменений и независимость команд.
✅ Нагрузка на отдельные функции распределена неравномерно – например, поиск товаров требует больше вычислительных мощностей, чем расчёт скидок.
✅ Отказоустойчивость критически важна.
✅ Частые релизы.


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

🦄 Микросервисная архитектура(MSA): погружение в детали 🦄

Микросервисная архитектура (MSA) – это эволюция сервис-ориентированной архитектуры (SOA), но более гибкая, независимая и масштабируемая.

Если монолит – это один большой блок,
а SOA – это несколько крупных сервисов,
то MSA – это сеть небольших сервисов, работающих как единая система.


Что такое микросервис (МС)?

▫️ Это небольшая, автономная служба, которая:
+ управляет данными одной сущности,
+ обслуживает строго один бизнес-процесс,
+ выполняет только одну простую функцию.
По сравнению с SOA, в MSA сервисы более узкоспециализированные и мЕньшие по размеру.

▫️ У каждого МС своя БД, API, кодовая база.

▫️ Каждый МС развернут на своём сервере, работает и релизится независимо от других.

▫️ МС не используют общую БД – каждая часть системы управляет своими данными.



👉 В МСА сервисы взаимодействуют между собой:
+ напрямую по API (REST, gRPC и другие),
+ через API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.


Набор МС для классического примера с Интернет-магазином:
🔹 Каталог товаров
🔹 Корзина
🔹 Заказы – получает данные из корзины и формирует заказ
🔹 Платежи
🔹 Управление скидками
🔹 Доставка
🔹 Уведомления (sms, email, push)
🔹 ЛК пользователей


👉 Плюсы MSA во многом совпадают с SOA:
✅ Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы
✅ Масштабируемость – можно увеличить нагрузку на конкретный сервис, не затрагивая всю систему
✅ Можно обновлять сервисы без даунтайма всей системы. А собственная БД гарантирует, что другие сервисы не будут затронуты
✅ Ошибки в одном сервисе не влияют на работу других
✅ Гибкость технологий


👉 Недостатки MSA:
❌ Сложность управления большим количеством сервисов. Мониторинг и логирование должны быть на высоком уровне, чтобы не терять сбои в отдельных частях системы
❌ Возможны задержки в работе из-за количества звеньев в цепочке обмена данными
❌ Нужна опытная команда


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

🪄 Сервис-ориентированная архитектура (SOA): погружение в детали 🪄

Сервис-ориентированная архитектура (SOA) представляет собой подход, который позволяет разрабатывать приложения как набор взаимосвязанных сервисов.

👉 Сервис – это маленький монолит.
👉 SOA – это набор маленьких монолитов, которые взаимодействуют друг с другом.


Когда мы думаем о серверной части приложения Backend, то в SOA надо представлять, что это НЕ одно большое приложение, как монолит, НЕ один прямоугольник “Backend” на схеме архитектуры, а много разных прямоугольников - сервисов, каждый из которых может:
+ отвечать за определенную группу функций,
+ иметь собственную БД,
+ иметь собственный API,
+ иметь собственную кодовую базу,
+ устанавливаться на отдельном сервере,
+ обновляться независимо от остальных.

👉 Эти сервисы общаются друг с другом, обычно через API или шину данных (ESB), для выполнения различных бизнес-задач.


Сервисы в SOA обычно выделяют по бизнес-контекстам или процессам, которыми они должны управлять.
В классическом примере с Интернет-магазином можно выделить сервисы:
▫️ товары,
▫️ корзина покупок,
▫️ платежи,
▫️ уведомления (sms, email, push),
▫️ ЛК пользователей.


Особенности SOA:

💪 Backend разбивается на независимые сервисы.

💪 Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы. Каждый сервис можно разрабатывать, тестировать, развертывать и масштабировать независимо.

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

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

💪 SOA позволяет использовать различные технологии и языки программирования в рамках одного проекта. То есть один сервис может быть на PHP, второй на Python, а все остальные сервисы на Java. Это позволяет программистам пробовать внедрять новые технологии в проекты при разработке новых сервисов.

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

🪲 Проблемы монолита: разбор на примерах 🪲


🔺1. Масштабируемость
Добавление новых функций и рост пользователей требуют больше затрат на серверные мощности (ресурсы): память, ядра процессора и другие.

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

> Планируется повышение нагрузки на приложение в 2 раза из-за новой рекламной акции: надо запустить еще несколько копий ВСЕГО такого же огромного монолита, к уже работающим параллельно копиям, чтобы выдержать нагрузку.

В архитектуре с сервисами добавить копии можно было бы только на основной сервис, который будут “атаковать” пользователи в ходе рекламной кампании.



🔺2. Сложность поддержки и развертывания
Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это почти недопустимо в современных реалиях. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.

> В существующем API-методе, в платежной части системы, нужно добавить к JSON-ответу дополнительное поле. Маленькая задача.

В условиях монолита, чтобы выпустить обновление на прод, придётся обновить весь сервер. На время обновления он может быть недоступен.

В условиях сервисов обновить надо только небольшой сервис платежей, который реализует этот API метод. Такое точечное обновление не будет блокировать другие важные функции системы в архитектуре с сервисами.


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

Для аналитиков полноценное погружение в проект может занимать от 3-х месяцев до года. И к концу испытательного срока вы все еще можете допускать ошибки проектирования и продолжать исследования дальше. Это считается нормой в монолитах.

В условиях архитектуры с сервисами аналитику часто достаточно знать только про свои сервисы и его БД, а также про API связанных сервисов внутри проекта и API внешних систем.



🔺4. Единая точка отказа
Монолит ломается целиком.
Из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Напротив, в сервисной архитектуре, остановят работу только те сервисы, которые работают с этой БД.



🔺5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов в разработке, что делает больно разработчикам.

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

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



Это основные проблемы монолитной архитектуры 😔

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

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

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

Сохраняем этот пост в памяти, чтобы быть готовыми к развернутым ответам 🙂

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

🛠 Монолитная архитектура: погружение в детали 🛠

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

Можно выделить две основные группы монолитов:

👉 Классический (жесткий) монолит: весь код Frontend и Backend в одном месте.

👉 Современный монолит: код UI (Frontend) выделяют в отдельную кодовую базу, но при этом проект может всё еще остаётся монолитным в части сервера (Backend).

Подробнее рассказала в картинках к посту 📚

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