🚓 УИИИИУ УИИИИИУ! 🚓
Полиция крутых вебинаров уже на месте!

Для начинающего специалиста тема архитектуры системы – это «чёрный ящик», к которому даже страшно прикасаться. И именно эту тему спрашивают у респондента на собеседованиях! 😔

Нет, не надо слов, не надо паники! (кто пропел эту строчку, ставь 👍)
Уже послезавтра мы расскажем и покажем про:
- интеграции,
- REST,
- монолит / SOA / MSA
и многое другое! Всё это вы не только узнаете, но и поймёте на практическом вебинаре «Проектирование архитектуры: от монолита к микросервисам» с Екатериной Ананьевой!

План вебинара:
1. Роль системного аналитика в проектировании архитектуры;
2. Знакомство с проектом для работы;
3. Проектирование монолита;
4. Переход к сервисам (SOA) и микросервисам (MSA);
5. Проблемы разделения монолита на микросервисы;
6. Что нужно знать системному аналитику про работу с архитектурой.

Эти навыки по проектированию архитектуры помогут выйти на новый качественный уровень в системном анализе и стать ценным специалистом в мире IT!

КОРОЧЕ ГОВОРЯ, НЕ ПРОПУСТИТЕ:

🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГЕСТИРОВАТЬСЯ

Увидимся на вебинаре! 😘

⭐️ RACI-матрица ⭐️

Английская аббревиатура расшифровывается так:
🟣Responsible (R) — исполнитель задачи.
🟣Accountable (A) — ответственный за выполнение задачи.
🟣Consulted (C) — консультирующий при выполнении задачи.
🟣Informed (I) — тот, кого нужно информировать при выполнении задачи.

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

У одной роли на разных этапах разработки ПО могут формироваться несколько зон ответственности, каждая из которых обычно обозначается соответствующей буквой — R, A, C или I.

Например, на этапе разработки требований к ПО роли внутри проектной команды можно распределить следующим образом:

🟢R - аналитик, который описывает требования к ПО;
🟢A - менеджер продукта, который отвечает за поставку решения;
🟢C - команда разработки и эксперты, которые будут консультировать аналитика для описания более качественных требований;
🟢I - служба поддержки, которую необходимо информировать о логике внутри решения и менеджер продукта, который должен быть в курсе статуса работ по задаче.

На этапе разработки ПО, когда требования были переданы на следующий этап, аналитик становится консультирующим (C), а команда разработки - исполнителями (R) и так далее.


В документации все роли удобно оформлять в виде таблицы со следующими заголовками в столбцах:
1. ФИО
Например: Иванов Иван Иванович
2. Роль
Например: Менеджер продукта
3. Зона ответственности по RACI-матрице
Например: A, I или Ответственный за выполнение задачи, Информированный
4. Контакт для связи

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

#hardGetAnalyst

⭐️ CRUD-модель ⭐️

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

В матрицу доступа входят:
- список ролей (Roles)
- перечень объектов и допустимых способов взаимодействия с ними (Permission)
И если роли можно определить с помощью RACI-матрицы, то разобраться со способами взаимодействия с данными поможет CRUD-модель.

CRUD-модель (аббревиатура от Create, Read, Update и Delete) – это стандартная модель возможностей работы с данными.


Эта модель определяет базовые функции работы с информацией:

🌟 Создание (Create) — это вид доступа, при котором можно добавлять новую информацию в ИС. Например, специалист подбора ассортимента может вносить новые товары, которые он нашёл у поставщиков.

📕 Чтение (Read) — это возможность видеть данные и объекты внутри системы. Этот тип доступа не даёт возможности выгрузить данные или как-то их изменять.

✏️ Изменение (Update)— можно корректировать данные внутри ИС. Например, дизайнер может изменить картинки для новых продуктов, когда они с фотографом сделали более удачные фото.

✖️ Удаление (Delete) — это удаление какой-либо информации. Например, специалист по подбору ассортимента решил удалить товар «Чипсы», потому что у поставщика чипсов проблемы с доставкой.

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

Так, например, одни пользователи могут только читать информацию, другие – создавать / редактировать / удалять только свои данные, а третьи – управлять порядком во всех данных (создавать / редактировать / удалять свои и чужие данные).


🥷: Ну а вообще навык работы по CRUD-модели – это отличная отправная точка при проектировании архитектуры системы. Ведь чтобы понять, какая логика должна располагаться внутри системы, необходимо знать, с какими функциональными потребностями в эту систему придут пользователи.

#hardGetAnalyst

⭐ УЖЕ СЕГОДНЯ! ⭐

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

На вебинаре вы:

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

Круто? КОНЕЧНО КРУТО!
Не упустите возможность разобраться в хардовой теме под чутким руководством Екатерины Ананьевой!

ИТАК:
🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 СЕГОДНЯ 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Увидимся там, чемпионы! 💃

😂👍👍❤️👌😅😊😊😍😘

❗️До начала 15 минут❗️

📹 Проектирование архитектуры: от монолита к микросервисам

Переходите по ссылке: https://pruffme.com/webinar/?id=00c7ce6f9597534c6124203cae11abb5 и начинаем!

🏬 Рассмотрим небольшой кейс:

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

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

Ну мы или не мы 30 января во время сбоя 😀

Всем отличных выходных, ребят!
Качественно отдыхайте, учитесь, гуляйте на свежем воздухе и будьте счастливыми 🐈

#GAhahaha
#GAfrindlyreminder