📑 Архитектурные принципы
Автор намерен поделиться архитектурными принципами, которые он считает основополагающими и широко применимыми при разработке приложений. Причиной публикации послужило частое игнорирование этих принципов на практике и отсутствие их краткого изложения в одном источнике.
Читать статью
Автор намерен поделиться архитектурными принципами, которые он считает основополагающими и широко применимыми при разработке приложений. Причиной публикации послужило частое игнорирование этих принципов на практике и отсутствие их краткого изложения в одном источнике.
Читать статью
📑 3 типа очередей в RabbitMQ: чем они отличаются и когда что использовать?
Какие параметры и аргументы очереди RabbitMQ отвечают за отказоустойчивость потокового конвейера на основе этого брокера сообщений: сходства и отличия кворумных очередей с классическими, а также как кролик косит под Kafka с версии 3.9 благодаря потоковым очередям.
Читать статью
Какие параметры и аргументы очереди RabbitMQ отвечают за отказоустойчивость потокового конвейера на основе этого брокера сообщений: сходства и отличия кворумных очередей с классическими, а также как кролик косит под Kafka с версии 3.9 благодаря потоковым очередям.
Читать статью
Проектирование_событийно_ориентированных_систем_Бен_Стопфорд.pdf
17.3 MB
Проектирование событийно-ориентированных систем.
Концепции и шаблоны проектирования сервисов потоковой обработки данных с использованием Apache Kafka
✍️ Автор: Бен Стопфорд
🗓 Год издания: 2019
🔤 Язык: русский
📚 Объём: 175 стр
Подробно раскрывает архитектурные возможности Kafka: журнал сообщений, масштабируемость, гарантии порядка и надежности, долговременное хранение.
Концепции и шаблоны проектирования сервисов потоковой обработки данных с использованием Apache Kafka
✍️ Автор: Бен Стопфорд
🗓 Год издания: 2019
🔤 Язык: русский
📚 Объём: 175 стр
Подробно раскрывает архитектурные возможности Kafka: журнал сообщений, масштабируемость, гарантии порядка и надежности, долговременное хранение.
Подборка полезных ссылок по API:
-OpenAPI/Swagger для начинающих
-Документирование API сервисов с помощью Swagger на примере фреймворков Express.js и Gin
-Что такое Swagger и как он облегчает работу с API
-Введение и руководство SwaggerHub
-Знакомство со спецификациями OpenAPI и Swagger
-Проектирование спецификации OpenAPI
-Практическое занятие "Создание спецификации OpenAPI"
-Описание OpenAPI для REST API
-OpenAPI/Swagger для начинающих
-Документирование API сервисов с помощью Swagger на примере фреймворков Express.js и Gin
-Что такое Swagger и как он облегчает работу с API
-Введение и руководство SwaggerHub
-Знакомство со спецификациями OpenAPI и Swagger
-Проектирование спецификации OpenAPI
-Практическое занятие "Создание спецификации OpenAPI"
-Описание OpenAPI для REST API
Преимущества BPMN AI-агентов
Интересная статья о том, как Camunda будет помогать внедрять ИИ агентов
Читать статью
Интересная статья о том, как Camunda будет помогать внедрять ИИ агентов
Читать статью
Проектирование GraphQL API
Цикл статей про аспекты работы с технологией GraphQL и разбор проектирования GraphQL API.
- Введение в GraphQL
- Схема GraphQL
- Архитектура и GraphQL
Цикл статей про аспекты работы с технологией GraphQL и разбор проектирования GraphQL API.
- Введение в GraphQL
- Схема GraphQL
- Архитектура и GraphQL
systems.education
■ Статья. Введение в GraphQL
📄Подборка статей
😀 Безопасность API (аутентификация и авторизация): проблемы, решения, практические рекомендации — статья на Хабре, в которой рассказывается о системном подходе к безопасности API
😀 Умный вайб-кодинг или семь раз отмерь, один раз сгенерь — статья на Хабре про практику AI-Driven разработки (AIDD)
😀 Интеграция и внешние идентификаторы — в статье на vc рассказывается, что может пойти не так при интеграции систем, и как можно хранить внешние идентификаторы
Please open Telegram to view this post
VIEW IN TELEGRAM
Большая подборка материалов по BPMN
BPMN - это графический язык, позволяющий визуализировать, документировать и анализировать бизнес-процессы.
BPMN помогает:
▫️Четко описывать процессы: Кто что делает, когда и как.
▫️Находить "узкие места": Где теряется время, ресурсы и деньги.
▫️Улучшать взаимодействие: Общий язык для бизнеса и IT.
▫️Совершенствовать автоматизацию: Подготовка процессов к внедрению IT-решений.
🔻 Постер BPMN 2.0 (rus)
🔻 Постер BPMN 2.0 (eng)
🔸Specification BPMN 2.0.(pdf) или About the Business Process Model And Notation Specification Version 2.0
🖇 Нотация BPMN
🖇 Элементы нотации BPMN
🖇 Как начать моделировать бизнес-процессы в BPMN
🖇 Нотация BPMN 2.0: ключевые элементы и описание
🖇 Краткое описание BPMN с примерами
🖇 Статьи по BPMN (Блог Дениса Котова)
🖇 Библиотека примеров бизнес-процессов в BPMN
🖇 ТОП-10 ошибок в BPMN-диаграммах
🖇 Профессиональное моделирование в BPMN, DMN и CMMN для бизнес-аналитика
🖇 Памятка по BPMN и BPMN-диаграммам
🖇 BPMN Tutorial: Learn Business Process Model and Notation
🖇 How to Draw BPMN 2.0 Business Process Diagram?
BPMN - это графический язык, позволяющий визуализировать, документировать и анализировать бизнес-процессы.
BPMN помогает:
▫️Четко описывать процессы: Кто что делает, когда и как.
▫️Находить "узкие места": Где теряется время, ресурсы и деньги.
▫️Улучшать взаимодействие: Общий язык для бизнеса и IT.
▫️Совершенствовать автоматизацию: Подготовка процессов к внедрению IT-решений.
🔻 Постер BPMN 2.0 (rus)
🔻 Постер BPMN 2.0 (eng)
🔸Specification BPMN 2.0.(pdf) или About the Business Process Model And Notation Specification Version 2.0
🖇 Нотация BPMN
🖇 Элементы нотации BPMN
🖇 Как начать моделировать бизнес-процессы в BPMN
🖇 Нотация BPMN 2.0: ключевые элементы и описание
🖇 Краткое описание BPMN с примерами
🖇 Статьи по BPMN (Блог Дениса Котова)
🖇 Библиотека примеров бизнес-процессов в BPMN
🖇 ТОП-10 ошибок в BPMN-диаграммах
🖇 Профессиональное моделирование в BPMN, DMN и CMMN для бизнес-аналитика
🖇 Памятка по BPMN и BPMN-диаграммам
🖇 BPMN Tutorial: Learn Business Process Model and Notation
🖇 How to Draw BPMN 2.0 Business Process Diagram?
Описание бизнес-процессов: цели, задачи и этапы - как структурировать работу компании по правилам
Как владельцу или руководителю компании понять, что происходит в его бизнесе? Как выявить слабые места, сократить потери и масштабироваться без хаоса? Ответ - грамотное описание бизнес-процессов, как почва для масштабирования, автоматизации и управляемости.
Читать
Как владельцу или руководителю компании понять, что происходит в его бизнесе? Как выявить слабые места, сократить потери и масштабироваться без хаоса? Ответ - грамотное описание бизнес-процессов, как почва для масштабирования, автоматизации и управляемости.
Читать
Общий подход к работе системного аналитика. Часть 1.
Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
Во‑первых, что такое бизнес‑контекст?
Это как фон, на котором мы пытаемся понять нашу задачу. В нашем случае, это может быть, например, понимание того, как сообщество общается сейчас, какие у него проблемы и какие цели оно преследует.
Здесь мы можем поговорить с руководством сообщества, пообщаться с его действующими участниками, изучить их текущие способы общения — социальные сети, форумы, вебинары и так далее.
Либо просто получить уже собранную информацию с описанием работы сообщества сейчас — это AS IS (описание «как есть» для проекта).
Теперь, что такое бизнес‑требования?
Это то, что бизнес хочет от будущей системы. В нашем случае, это может быть, например, желание сделать процесс регистрации на вебинары проще и удобнее, или желание собрать всю информацию из разных соцсетей в одном месте.
Бизнес‑требования мы также обычно собираем на встречах с заказчиком, проводим интервью и обсуждения.
Это To Be — как должно быть в результате разработки.
Важно понимать, что первоначально собранные требования часто бывают не полными или не точными.
Задача системного аналитика — уточнить эти требования, не погружая заказчика в технические детали реализации, но уже примерно представляя, что будет «под капотом».
Мы возвращаемся к заказчику или потенциальным пользователям с вопросами, уточняем детали, проверяем понимание, проводим дополнительные интервью, если необходимо, чтобы убедиться, что мы все правильно поняли.
По итогу этого этапа у нас должна быть ясная картина того, как работает бизнес сейчас, и чего он хочет от новой системы. И все это мы оформляем в виде требований, которые дальше передадим команде разработки.
Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
Во‑первых, что такое бизнес‑контекст?
Это как фон, на котором мы пытаемся понять нашу задачу. В нашем случае, это может быть, например, понимание того, как сообщество общается сейчас, какие у него проблемы и какие цели оно преследует.
Здесь мы можем поговорить с руководством сообщества, пообщаться с его действующими участниками, изучить их текущие способы общения — социальные сети, форумы, вебинары и так далее.
Либо просто получить уже собранную информацию с описанием работы сообщества сейчас — это AS IS (описание «как есть» для проекта).
Теперь, что такое бизнес‑требования?
Это то, что бизнес хочет от будущей системы. В нашем случае, это может быть, например, желание сделать процесс регистрации на вебинары проще и удобнее, или желание собрать всю информацию из разных соцсетей в одном месте.
Бизнес‑требования мы также обычно собираем на встречах с заказчиком, проводим интервью и обсуждения.
Это To Be — как должно быть в результате разработки.
Важно понимать, что первоначально собранные требования часто бывают не полными или не точными.
Задача системного аналитика — уточнить эти требования, не погружая заказчика в технические детали реализации, но уже примерно представляя, что будет «под капотом».
Мы возвращаемся к заказчику или потенциальным пользователям с вопросами, уточняем детали, проверяем понимание, проводим дополнительные интервью, если необходимо, чтобы убедиться, что мы все правильно поняли.
По итогу этого этапа у нас должна быть ясная картина того, как работает бизнес сейчас, и чего он хочет от новой системы. И все это мы оформляем в виде требований, которые дальше передадим команде разработки.
❤1👍1
Шпаргалка на тему «Выявление требований»
Сбор требований — это основа успеха любого проекта. Ошибки на этом этапе могут привести к переделкам, срыву сроков и недовольству заказчика.
🚀 Для начала начните с подготовки:
Перед встречей с заказчиком:
- Изучите контекст. Узнайте, чем занимается компания, какие у нее бизнес-цели, кто конкуренты. Почитайте документацию, если она есть (например, ТЗ прошлых проектов)
- Определите стейкхолдеров. Кто принимает решения? Кто будет пользоваться системой? Не упустите ни одну группу: менеджеры, конечные пользователи, технические специалисты
- Сформулируйте гипотезы. Запишите свои предположения о потребностях заказчика — это поможет задавать точные вопросы.
📋 Техники сбора требований
Используйте комбинацию методов:
- Интервью.
Задавайте открытые вопросы: «Расскажите, как сейчас проходит процесс X», избегайте наводящих вопросов: «Вам же нужна автоматизация, верно?»
- Воркшопы. Совместное обсуждение с использованием доски (физической или цифровой) помогает визуализировать требования.
- Наблюдение. Посмотрите, как пользователи работают в текущей системе — это выявит неочевидные проблемы.
- Прототипы. Эскизы интерфейсов или схемы процессов помогут заказчику конкретизировать пожелания.
✅ Как готовиться к интервью
- Составьте чек-лист вопросов, но будьте готовы отклониться от него. Примеры:
▫️ «Что вас не устраивает в текущем процессе?»
▫️ «Какие ограничения (бюджет, сроки, технологии) важно учесть?»
- Используйте технику «5 почему». Если заказчик говорит: «Нам нужна кнопка здесь», спросите: «Почему это важно?», пока не докопаетесь до корневой потребности.
- Записывайте всё. Используйте диктофон (с разрешения!) или конспектируйте ключевые тезисы.
📑 Документирование требований
📎 Статья: Стандарты и шаблоны для ТЗ на разработку ПО
- Структурируйте информацию. Разделяйте требования на:
- Функциональные (что система должна делать).
- Нефункциональные (производительность, безопасность, удобство).
- Ограничения (сроки, бюджет, законодательство).
- Используйте шаблоны. Например, User Stories (*«Как [роль], я хочу [действие], чтобы [цель]»*) или Use Case-диаграммы.
- Проверяйте требования на SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.
❗️ Чего делать НЕ стоит
- Не додумывайте за заказчика. Если что-то непонятно — переспрашивайте.
- Не игнорируйте конфликтующие требования. Если мнения стейкхолдеров расходятся, зафиксируйте это и обсудите приоритеты.
- Не используйте технический жаргон. Говорите на языке заказчика.
- Не спешите. Лучше потратить время на уточнение, чем переделывать готовый функционал.
✅ Проверка и согласование
- Проведите ревью. Убедитесь, что требования:
- Полные (охватывают все сценарии).
- Непротиворечивые.
- Тестируемые (можно проверить результат).
- Утвердите документ. Подпись заказчика формализует договоренности и снижает риски.
____
Советы из личного опыта
- Всегда спрашивайте: «Что будет, если этого НЕ сделать?» — это помогает отсечь «хотелки» от критически важных требований.
- Добавляйте примеры из реальной жизни в документацию («Для заказа клиент заполняет форму, как на Рис. 1»).
- Используйте инструменты: Jira, Confluence, Miro, Draw.io — они упрощают визуализацию и совместную работу.
Финальный лайфхак: Требования меняются. Заложите в процесс регулярные встречи для актуализации документации и будьте готовы к итерациям.
Сбор требований — это основа успеха любого проекта. Ошибки на этом этапе могут привести к переделкам, срыву сроков и недовольству заказчика.
Перед встречей с заказчиком:
- Изучите контекст. Узнайте, чем занимается компания, какие у нее бизнес-цели, кто конкуренты. Почитайте документацию, если она есть (например, ТЗ прошлых проектов)
- Определите стейкхолдеров. Кто принимает решения? Кто будет пользоваться системой? Не упустите ни одну группу: менеджеры, конечные пользователи, технические специалисты
- Сформулируйте гипотезы. Запишите свои предположения о потребностях заказчика — это поможет задавать точные вопросы.
📋 Техники сбора требований
Используйте комбинацию методов:
- Интервью.
Задавайте открытые вопросы: «Расскажите, как сейчас проходит процесс X», избегайте наводящих вопросов: «Вам же нужна автоматизация, верно?»
- Воркшопы. Совместное обсуждение с использованием доски (физической или цифровой) помогает визуализировать требования.
- Наблюдение. Посмотрите, как пользователи работают в текущей системе — это выявит неочевидные проблемы.
- Прототипы. Эскизы интерфейсов или схемы процессов помогут заказчику конкретизировать пожелания.
- Составьте чек-лист вопросов, но будьте готовы отклониться от него. Примеры:
▫️ «Что вас не устраивает в текущем процессе?»
▫️ «Какие ограничения (бюджет, сроки, технологии) важно учесть?»
- Используйте технику «5 почему». Если заказчик говорит: «Нам нужна кнопка здесь», спросите: «Почему это важно?», пока не докопаетесь до корневой потребности.
- Записывайте всё. Используйте диктофон (с разрешения!) или конспектируйте ключевые тезисы.
📑 Документирование требований
- Структурируйте информацию. Разделяйте требования на:
- Функциональные (что система должна делать).
- Нефункциональные (производительность, безопасность, удобство).
- Ограничения (сроки, бюджет, законодательство).
- Используйте шаблоны. Например, User Stories (*«Как [роль], я хочу [действие], чтобы [цель]»*) или Use Case-диаграммы.
- Проверяйте требования на SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.
- Не додумывайте за заказчика. Если что-то непонятно — переспрашивайте.
- Не игнорируйте конфликтующие требования. Если мнения стейкхолдеров расходятся, зафиксируйте это и обсудите приоритеты.
- Не используйте технический жаргон. Говорите на языке заказчика.
- Не спешите. Лучше потратить время на уточнение, чем переделывать готовый функционал.
- Проведите ревью. Убедитесь, что требования:
- Полные (охватывают все сценарии).
- Непротиворечивые.
- Тестируемые (можно проверить результат).
- Утвердите документ. Подпись заказчика формализует договоренности и снижает риски.
____
Советы из личного опыта
- Всегда спрашивайте: «Что будет, если этого НЕ сделать?» — это помогает отсечь «хотелки» от критически важных требований.
- Добавляйте примеры из реальной жизни в документацию («Для заказа клиент заполняет форму, как на Рис. 1»).
- Используйте инструменты: Jira, Confluence, Miro, Draw.io — они упрощают визуализацию и совместную работу.
Финальный лайфхак: Требования меняются. Заложите в процесс регулярные встречи для актуализации документации и будьте готовы к итерациям.
Please open Telegram to view this post
VIEW IN TELEGRAM
Практика Kafka: проектирование топиков и обмен сообщениями
В статье рассказывается о структуре и обработке сообщений Kafka:
• более подробно разбирается структура сообщения в Kafka с точки зрения продюсера;
• формулируются ключевые требования к проектированию шины данных на основе Apache Kafka;
• затрагивается разработка собственных продюсера и консьюмера на Python;
• на практике увидите, что такое JSON‑сериализация и десериализация;
Читать статью
В статье рассказывается о структуре и обработке сообщений Kafka:
• более подробно разбирается структура сообщения в Kafka с точки зрения продюсера;
• формулируются ключевые требования к проектированию шины данных на основе Apache Kafka;
• затрагивается разработка собственных продюсера и консьюмера на Python;
• на практике увидите, что такое JSON‑сериализация и десериализация;
Читать статью
Подборка полезных ссылок по диаграммам. Сохраняй, чтобы не потерять!
-Краткое описание нотации BPMN
-Что такое нотация моделирования бизнес-процессов
-UML: обзор основных типов диаграмм, диаграмма Классов. Часть 1
-Разновидности диаграмм UML
📱 Что такое UML за 7 минут: Диаграмма классов, последовательностей, состояний и деятельности
-Краткое описание нотации BPMN
-Что такое нотация моделирования бизнес-процессов
-UML: обзор основных типов диаграмм, диаграмма Классов. Часть 1
-Разновидности диаграмм UML
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Преобразование компетенций бизнес-аналитика в ИТ с развитием ИИ-технологии
"ИИ — это не просто «еще один инструмент» для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.
В статье рассматриваются:
- Преобразование компетенций и ежедневной работы БА:
- Автоматизация рутины (где ИИ — «гипер-инструмент»).
- Появление новых компетенций (супер-сил).Сокращение численности команд.
- Примеры и тренды в российских IT-компаниях.
- Сложности перехода к новой логике."
Читать статью
"ИИ — это не просто «еще один инструмент» для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.
В статье рассматриваются:
- Преобразование компетенций и ежедневной работы БА:
- Автоматизация рутины (где ИИ — «гипер-инструмент»).
- Появление новых компетенций (супер-сил).Сокращение численности команд.
- Примеры и тренды в российских IT-компаниях.
- Сложности перехода к новой логике."
Читать статью
Для чего нужно моделировать процессы
Любой бизнес- или системный процесс, который подлежит анализу, можно зафиксировать разными методами. Например:
💭 проговорить устно,
📝 оформить в текстовом виде или структурировать в таблицах.
Однако наиболее универсальным и наглядным способом, который одинаково хорошо воспринимается заказчиками, разработчиками и архитекторами, считается представление процессов через модели
.
Модель процесса — это совокупность диаграмм и сопроводительных материалов, описывающих последовательность работ или действий, а также внешние и внутренние факторы, влияющие на выполнение этих шагов.
Ключевой результат процессного моделирования — это чёткая визуализация порядка операций и условий, обеспечивающих достижение целевого результата.
Используя моделирование процессов, аналитик получает:
1️⃣ наглядный формат фиксации текущего состояния (AS IS) функционирования системы или бизнеса;
2️⃣ ясное представление целевого состояния (TO BE) процесса после внедрения планируемых изменений;
3️⃣ диаграммы, отображающие участников, входные и выходные данные, последовательные шаги и возможные альтернативные сценарии развития.
В IT-проектах моделирование процессов — одна из ключевых компетенций аналитика. Это инструмент, который позволяет эффективно взаимодействовать с представителями разных ролей: от бизнес-заказчиков до системных архитекторов. Чёткое и лаконичное донесение структуры процессов в виде моделей ускоряет согласование требований и проектирование решения.
Любой бизнес- или системный процесс, который подлежит анализу, можно зафиксировать разными методами. Например:
💭 проговорить устно,
📝 оформить в текстовом виде или структурировать в таблицах.
Однако наиболее универсальным и наглядным способом, который одинаково хорошо воспринимается заказчиками, разработчиками и архитекторами, считается представление процессов через модели
.
Модель процесса — это совокупность диаграмм и сопроводительных материалов, описывающих последовательность работ или действий, а также внешние и внутренние факторы, влияющие на выполнение этих шагов.
Ключевой результат процессного моделирования — это чёткая визуализация порядка операций и условий, обеспечивающих достижение целевого результата.
Используя моделирование процессов, аналитик получает:
1️⃣ наглядный формат фиксации текущего состояния (AS IS) функционирования системы или бизнеса;
2️⃣ ясное представление целевого состояния (TO BE) процесса после внедрения планируемых изменений;
3️⃣ диаграммы, отображающие участников, входные и выходные данные, последовательные шаги и возможные альтернативные сценарии развития.
В IT-проектах моделирование процессов — одна из ключевых компетенций аналитика. Это инструмент, который позволяет эффективно взаимодействовать с представителями разных ролей: от бизнес-заказчиков до системных архитекторов. Чёткое и лаконичное донесение структуры процессов в виде моделей ускоряет согласование требований и проектирование решения.
Вижу — значит, понимаю: зачем нужны прототипы
Прототип — это способ увидеть проблему до того, как она съест ваш бюджет, сроки и репутацию.
➡️ Когда делать прототип?
🔚 У вас есть непонятные требования
🔚 Клиент говорит «Узнаю, когда увижу»
🔚 Риски — высокие, цена ошибки — ещё выше
🔚 Интерфейс критичен для продукта
🔚 Нужно быстро получить фидбек
➡️ Какие бывают прототипы?
🔚 Одноразовый — быстрое прояснение требований, наброски экранов
🔚 Эволюционный — постепенная сборка функционала, приближающаяся к финальному продукту
🔚 Экспериментальный — проверка архитектуры, производительности, технической реализуемости
➡️ Прототип это не Продукт
Важно: прототип — это НЕ MVP, не финал, не половина разработки. Это инструмент. И да, его можно сделать в PowerPoint, Figma или даже на бумаге. Главное — не застревать в отрисовке, а быстро получать обратную связь.
➡️ Этапы:
🔚 Сценарии использования
🔚 Карты экранов / диалогов
🔚 Вайрфрейм
🔚 Фидбек от пользователей
🔚 Дизайн интерфейса
Чем больше итераций — тем меньше сюрпризов.
➡️ Риски при работе с прототипами
🔚 Заигрались и ушли в перфекционизм
🔚 Клиенты начинают думать, что это уже рабочая система
🔚 Архитектура не выдержит масштабирования
🔚 Команда тратит больше времени на отрисовку, чем на анализ
Прототип — это способ увидеть проблему до того, как она съест ваш бюджет, сроки и репутацию.
Важно: прототип — это НЕ MVP, не финал, не половина разработки. Это инструмент. И да, его можно сделать в PowerPoint, Figma или даже на бумаге. Главное — не застревать в отрисовке, а быстро получать обратную связь.
Чем больше итераций — тем меньше сюрпризов.
Please open Telegram to view this post
VIEW IN TELEGRAM