💠 Декомпозиция требований и задач

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

Горизонтальная и вертикальная декомпозиция

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

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

Методы декомпозиции

1️⃣ Несколько потребностей: задача делится по союзам «и», «или». Например, «сделать заказ и оплатить картой или бонусами» разбивается на три подзадачи.

2️⃣ Сценарии использования: задача делится по основному и альтернативным путям. Например, «купить товар» разбивается на подзадачи «сравнить товары», «добавить в избранное», «узнать о наличии» и т.д.

3️⃣ Разбиение по позитивным и негативным сценариям: по ожидаемому и неожиданному поведению функционала. Например, «совершить покупку по карте» разбивается на подзадачи «совершить покупку без ошибок», «обработать ошибку при недостатке средств на карте», «обработать ошибку при блокировке учетной записи» и т.д.

4️⃣ Разбиение по этапам процесса: по последовательным шагам, которые составляют процесс. Например, «совершить покупку в интернет магазине» разбивается на подзадачи «войти в личный кабинет», «просмотреть товары в корзине», «сформировать счет на оплату» и т.д.

5️⃣ От простого к сложному: по уровню сложности функционала. Например, «сделать баннер» разбивается на подзадачи «показать одну картинку», «сделать сетку из картинок», «сделать карусель из картинок» и т.д.

6️⃣ Операции (CRUD): задача делится по операциям создания, чтения, обновления и удаления. Например, «оформить заказ» разбивается на подзадачи «создать заказ», «просмотреть заказ», «редактировать заказ» и «удалить заказ».

7️⃣ Варианты интерфейса: по поддержке разных языков, устройств, браузеров и т.д. Например, «сделать сайт мультиязычным» разбивается на подзадачи «сделать русскоязычную версию», «сделать англоязычную версию» и т.д.

8️⃣ Разбиение по типам платформы/ОС. Например, «оплатить покупку» разбивается на подзадачи «оплатить покупку на ПК», «оплатить покупку на планшете», «оплатить покупку на смартфоне» и т.д.

9️⃣ Разделение по ролям. Например, «сделать сайт» разбивается на подзадачи «сделать сайт для анонимных пользователей», «сделать сайт для авторизованных пользователей», «сделать бэкофис для пользователей колл-центра» и т.д.

🔟 Разбиение по типам данных и параметрам: по разным типам данных или параметрам, которые функционал должен обрабатывать. Например, «поиск товаров» разбивается на подзадачи «поиск по тексту», «поиск по коду», «поиск по регулярным выражениям» и т.д.

📄 Статьи
1. 8 методов декомпозиции задач
2. Паттерны декомпозиции User Story / задач (из России с VPN)
3. Как справиться с декомпозицией задач и не перестараться + видео
4. Story Mapping на примере пиццерии
5. SPIDR — пять простых техник для создания идеально разделенной пользовательской истории
6. Разбиение пользовательских историй – метод гамбургера

⏯ Видео
1. Декомпозиция задач и аналитик — Михаил Максимов
2. Как мы разбирали слона. Целые, сломанные и лишние детали — доклад Алексея Козлова на конференции Analyst Days-7
3. User Story Splitting: как и зачем добавлять детали пользовательским историям — Юрий Куприянов
4. Использование Use case и User story для декомпозиции задач — Михаил Максимов
5. Плейлист про декомпозицию задач

#требования

🐍 Подборка материалов по изучению Python с нуля

Важно ли аналитику уметь программировать?

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

Главное здесь не просто знание синтаксиса языка (это можно загуглить или спросить у нейросети), а умение строить алгоритмы, понимание, как требования ложатся на код.

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

🎓 Бесплатные курсы
1. "Поколение Python": курс для начинающих — самый популярный курс по Питону с нуля на Stepik
2. "Поколение Python": курс для продвинутых — курс для тех, кто прошёл предыдущий или у кого уже есть базовые знания по программированию
3. Программирование на Python — второй по популярности курс по Питону с нуля на Stepik
4. Python: основы и применение — продолжение предыдущего курса, а также для тех, кто имеет базовые навыки Питона
5. pythontutor.ru — интерактивный самоучитель, много задач, которые можно проверять автоматически и смотреть решения других людей
6. Python в примерах и задачах — курс от Дальневосточного федерального университета
7. Видеокурс от Школы бэкенд-разработки Яндекса — для продвинутых, поможет научиться промышленной разработке на Python
8. Тренажер по Python от Каталог-курсов.ру
9. Автоматизация тестирования с помощью Selenium и Python

⏯ Видео
1. Питон за час
2. Python-джедай (продолжение Питон за час)
3. Плейлист Python для начинающих
4. МФТИ, цикл лекций курса «Практики программирования»
5. Python программирование — плейлист для новичков
6. Язык программирования PYTHON для начинающих — 88 видео
7. Асинхронность в Python — плейлист для продвинутых
8. Разработка Telegram Ботов на Python с нуля

📚 Книги
(ссылки ведут на pdf)
1. Эрик Мэтиз. Изучаем Python: программирование игр, визуализация данных, веб-приложения
2. Пол Бэрри. Изучаем программирование на Python
3. Эл Свейгарт. Автоматизация рутинных задач с помощью Python
4. Марк Лутц. Python. Карманный справочник
5. Аллен Б. Дауни. Основы Python. Научитесь думать как программист

🌐 Полезные сайты
1. "Укус Питона" — "A Byte of Python" по-русски — подробный справочник по Питону с объяснениями
2. Запустить код пошагово с визуализацией
3. Визуализатор рекурсии — построить наглядное дерево вызовов
4. Простейший самоучитель по Python — можно использовать в качестве справочника
5. Репозиторий 30-Days-Of-Python (англ)
6. Freecodecamp — интерактивный учебник по Python (русского нет, зато есть украинский)
7. Онлайн-тренажёр «Прогноз погоды на Python» — интерактив от Яндекса по созданию программы, которая показывает температуру в любом городе мира
8. Адаптивный тренажер Python — несколько десятков разнообразных задач на Python разных уровней сложности
9. Тренажер “Codechick” — сборник практических заданий по Python, отсортированных по уровню сложности

Django
1. Курс видео по Django от EngineerSpock
2. Django 3 для python (уроки)
3. Создание сайта на Django
4. Django Web Development with Python (на русском)

💻 IDE
1. PyCharm: Windows / Linux / Mac
2. Spider
3. Непосредственно Python

📎 Ещё подборки и ссылки
1. Обучающие материалы по питону (roadmap) — огромная подборка материалов от корки до корки
2. 15+ небанальных ресурсов для начинающего/продолжающего Python-разработчика
3. 16 лучших сайтов уроков и заданий по Python в 2023 года
4. 144 книги по Python — можно скачать бесплатно
5. Бесплатные книги по Питону на все темы

#подборка

Оркестрация и хореография в микросервисной архитектуре

В микросервисной архитектуре для организации взаимодействия микросервисов между собой используют два подхода: оркестрацию и хореографию.

Оркестрация – это подход, при котором есть центральный сервис (оркестратор), который координирует и управляет всеми остальными сервисами. Оркестратор знает всю логику бизнес-процесса и вызывает нужные сервисы в нужном порядке, передавая им необходимые данные и получая от них ответы. Оркестратор может использовать разные способы коммуникации с сервисами, например, REST, RPC, очереди сообщений и т.д. Пример "коробочного" решения для оркестрации: Camunda

✅ Плюсы оркестрации

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

⛔️ Минусы оркестрации

💩Высокая связанность между сервисами, так как оркестратор зависит от интерфейсов и доступности всех сервисов, а сервисы зависят от того, что оркестратор передает им в качестве входных данных
💩Оркестратор становится узким местом и единой точкой отказа
💩Добавление новых сервисов или изменение порядка вызовов требует изменения оркестратора

Хореография – это подход, при котором нет центрального сервиса, который управляет всеми остальными. Вместо этого каждый сервис самостоятельно решает, что и когда делать, на основе событий, которые он получает от других сервисов. Сервисы публикуют события в общий канал (например, топик в Kafka) и подписываются на события, которые их интересуют. Таким образом, формируется цепочка реакций на события, которая реализует бизнес-процесс.

✅ Плюсы хореографии

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

⛔️ Минусы хореографии

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

Что лучше?

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

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

📎 Статьи
1. Оркестрация и хореография микросервисов в EDA-архитектуре — немного теории + небольшая практика
2. Мониторинг и управление потоком задач в рамках взаимодействия микросервисов — здесь рассматривается оркестрация и хореография на практике
3. Сравнение подходов к реализации распределенных транзакций для микросервисов + более краткая версия статьи
3. Camunda: автоматизация бизнес-процессов и оркестрация микросервисов
4. Orchestration vs Choreography
5. Аналитика микросервисов. Практический опыт аналитика в enterprise
6. Паттерн Saga в микросервисной архитектуре
7. Сага о консистентности данных
8. Сага распределенных транзакций

⏯ Видео
1. Оркестрация и хореография. Как построить бизнес-процесс в зоопарке микросервисов — воркшоп Андрея Буракова на конференции Analyst Days-14 + ответы на вопросы по результатам воркшопа
2. Применение camunda для оркестрации микросервисов
3. Обзор паттернов интеграции микросервисов

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

Паттерны API Gateway и BFF

В микросервисной архитектуре часто возникает вопрос, как организовать взаимодействие между клиентами (например, веб-приложениями или мобильными приложениями) и сервисами, которые предоставляют API. Для этого существуют два популярных паттерна: API Gateway и BFF (Backend For Frontend).

API Gateway – это компонент, который выступает в качестве единой точки входа в систему для всех клиентов. принимает запросы от клиентов, перенаправляет их к соответствующим микросервисам и возвращает ответы обратно к клиентам.

✅ Преимущества API Gateway

1️⃣ Упрощает использование API, так как клиентам не нужно знать о расположении и протоколах каждой системы и сервиса. При этом системы-источники данных избавляются от необходимости адаптироваться к каждому потребителю по отдельности

2️⃣ Обеспечивает единообразие и стандартизацию API для всех клиентов

3️⃣ Обеспечивает безопасность, так как API Gateway может осуществлять аутентификацию и авторизацию клиентов перед дальнейшими вызовами. Также API Gateway может вводить ограничения частоты запросов

4️⃣ Мониторинг и сбор показателей, что упрощает решение проблем и инцидентов

5️⃣ Сокращение количества сетевых вызовов, так как API Gateway может агрегировать и трансформировать данные из разных микросервисов в один ответ

6️⃣ Повышение производительности системы в целом и снижение нагрузки на системы-источники данных, так как API Gateway может кешировать данные, фильтровать запросы и применять политики доступа.
Однако зачастую кэширование на уровне API Gateway создаёт сложности согласованности данных (ведь у конечной системы тоже свой кэш), размазывает часть логики из разных систем на один компонент.

⛔️ Недостатки API Gateway

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

BFF – это вариация паттерна API Gateway, при которой для каждого типа клиента создается свой собственный API Gateway. Например, для сайта свой Web BFF, для приложения клиента App BFF, для ЛК сотрудника Emp BFF.

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

✅ Преимущества BFF по сравнению с единым API Gateway для всех клиентов

1️⃣ Позволяет создавать более гибкие и настраиваемые API для каждого клиента, учитывая его различия в протоколах, форматах данных, функциональности и интерфейсе

2️⃣ Уменьшает объем передаваемых данных, так как BFF может отфильтровать и сократить ненужную информацию для клиента

3️⃣ Повышает независимость и ответственность команд, так как каждая команда может владеть и управлять своим BFF

⛔️ Недостатки BFF

В дополнение к ограничениям API Gateway, использование BFF может привести к дублированию кода и логики, если для разных клиентов требуются похожие функции

Промышленные решения для API Gateway и BFF
— Kong
— Istio
— Yandex Cloud

📎 Статьи
1. Что такое API-шлюзы и Gateway API
2. Pattern: API Gateway / Backends for Frontends — Крис Ричардсон
3. Pattern: Backends For Frontends — Сэм Ньюмэн
4. Опыт создания API Gateway
5. Использование паттерна BFF для создания общих типов в бэкенде и фронтенде

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

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

Use Case. Как описывать и использовать

Use Case (синонимы: вариант использования, прецедент, сценарий) – это способ описания сценария взаимодействия пользователя с системой. Use Case помогает определить функциональные требования к системе, а также показать, как она взаимодействует с другими участниками.

UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: что система должна сделать, чтобы актор достиг своей цели, а не как это должно быть реализовано в коде.

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

Use Case может состоять из следующих элементов

💩Название. Кратко и однозначно отражает суть сценария
💩Цель. Зачем нужен этот сценарий? Для чего? Без цели сценарий бесполезен
💩Акторы. Участники, которые вовлечены в сценарий (человек или система)
💩Предусловия. Условия, которые должны быть выполнены перед началом сценария
💩Триггеры. События, которые запускают основной поток.
💩Основной поток. Последовательность шагов, которые выполняются акторами для достижения цели сценария. Каждый шаг описывает действие актора и реакцию системы
💩Альтернативные потоки. Варианты развития событий, которые отличаются от основного потока. Они могут быть вызваны ошибками, исключениями, выбором пользователя (if-else) или другими причинами
💩Результат (Постусловия). Что получится на выходе сценария
💩Бизнес-правила. Регламенты или ограничения, влияющие на Use Case

Как прорабатывать требования в формате Use Case

1️⃣ Определите акторов – людей и системы
2️⃣ Составьте список всех UC, которые задействуют акторов
3️⃣ Для каждого UC определить цель, предусловия, постусловия
4️⃣ Опишите основной поток каждого UC
5️⃣ Дополните описания UC альтернативными потоками

Use Case может быть описан в виде таблицы, текстом или на диаграмме UML.

Use Case 🆚 User Story

🔸 User Story — это краткое описание того, что хочет достичь пользователь, используя систему. Они обычно начинаются со слов «как пользователь, я хочу… «, и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.

🔹 Use Case — это детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Use Case описывают, как система должна реагировать на действия пользователя.

📖 Книга: Алистер Коберн, «Современные методы описания функциональных требований»

📎 Статьи
1. Алгоритм описания функциональных требований к системе в формате Use Case — А. Вичугова и А. Гасраталиева / Systems Education
2. USE CASES. Что это такое и зачем они нужны?
3. Инструкция по работе со сценариями использования для молодого системного аналитика
4. Как мы создали шаблон функциональных требований к разработке ПО — от аналитиков МТС
5. Двадцать лет с юзкейсами: выжимаем практический опыт — статья от аналитика Qiwi
6. Усиление методики Use Case данное в книге Алистера Кобёрна — Евгений Скориков
7. Варианты на все случаи жизни: как написать полезный use case
8. Use Case и User Story: в чем разница
9. Ликбез по UML Use Case диаграмме

⏯ Видео
1. Использование Use case и User story для декомпозиции задач — Михаил Максимов
2. Фиксация требований с помощью Use Case / Демо-занятие курса «Системный аналитик»
3. Use Cases. Разбор вопросов и примеров диаграмм и описания от ЛАФ: часть 1 и часть 2
4. Идеальный USE CASE: как описать сценарий, чтобы его не вернули на доработку — MediaSoft
5. Как написать сценарий использования

#требования

System Design. Подготовка к сложному интервью

✍️ Автор: Алекс Сюй
🗓 Год издания: 2022
🔤 Язык: русский
📚 Объём: 304 стр.

Описание:
Интервью по System Design (проектированию ИТ-систем) очень популярны у работодателей, на них легко проверить ваши навыки общения и оценить умение решать реальные задачи.
Пройти такое собеседование непросто, поскольку в проектировании ИТ-систем не существует единственно правильных решений. Речь идет о самых разнообразных реальных системах, обладающих множеством особенностей. Вам могут предложить выбрать общую архитектуру, а потом пройтись по всем компонентам или, наоборот, сосредоточиться на каком-то одном аспекте. Но в любом случае вы должны продемонстрировать понимание и знание системных требований, ограничений и узких мест.
Правильная стратегия и знания являются ключевыми факторами успешного прохождения интервью!

Что внутри?
💩Инсайдерская информация: что на самом деле нужно интервьюерам
💩4-х шаговый подход к решению любой задачи system design
💩16 вопросов из реальных интервью с подробными решениями.
💩188 диаграмм, наглядно объясняющих, как работают реальные системы.

#проектирование

JSON и JSON Schema

JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт.

Где используется
JSON независим от языков программирования и используется повсеместно, например:
💩при обмене данными через API. Например, мы можем как один из вариантов передавать body HTTP-запроса в формате JSON (но не обязательно только JSON!)
💩при создании параметров конфигурации для систем и сервисов
💩в NoSQL базах данных, например, в MongoDB

Синтаксис
Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}.
💩Ключ – это название параметра, пишется в двойных кавычках
💩Значение для ключа указывается после двоеточия
💩Между парами ключ-значение ставится запятая. После последней пары запятая не ставится
💩Писать ключи можно в любом порядке

Типы данных
💩Строка – "name": "Вася"
💩Число – целое или с запятой – "years": 24
💩boolean – true или false – "resident": true
💩null – пустое значение – "children": null
💩Массив – "experience": [ "Повар", 2, "Аналитик", 1 ]
💩Объект – "experience": { "Повар": 2, "Аналитик": 1 }

Классический JSON (по стандарту RFC 8259) не поддерживает комментарии. Однако существует расширение стандартного JSON – JSON5, в котором можно вставлять комментарии.

А где же тип “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке по ISO 8601, например, "2012-04-21T18:25:43-05:00".

JSON Schema

JSON Schema – это способ описания структуры и ограничений JSON-документов. Схема создана для описания JSON-данных, но и сама она при этом является JSON-объектом. С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей.

В отличие от XML-схемы, которая имеет стандарт и строго диктует определение документа в рамках XML, JSON-схема более гибкая и простая.

Применение JSON Schema

1️⃣ Описание формата данных в API-контрактах, которое читается машиной и понятно человеку

2️⃣ Валидация данных в JSON-документах. Здесь имеется в виду не просто проверка на корректность формата, а проверка специфических требований и ограничений

3️⃣ Автоматическая генерация примеров запросов и ответов API: JSON Schema позволяет генерировать динамические данные, соответствующие схеме. Эти примеры ответов можно использовать для создания заглушек

4️⃣ Создание автоматической документации к API

5️⃣ Автоматическая генерация кода. На основе схемы можно создавать SDK для API на любой платформе

📄 Спецификации
1. RFC 8259 — про JSON
2. ISO 8601 — про формат дат
3. JSON Schema
4. JSON5

📎 Материалы по JSON
0. Пример JSON
1. Что такое JSON и как с ним работать
2. Хорошо написанная статья в англоязычной Википедии
3. Типичные ошибки в JSON
4. JSON онлайн редактор
5. JSON конвертер в YAML
6. XML конвертер в JSON
7. YAML конвертер в JSON, XML, CSV

📎 Материалы по JSON Schema
1. Объяснение JSON-схемы с примерами от ВК
2. JSON Schema. Быть или не быть?
3. Понимание JSON схемы
4. Пример JSON-схемы
5. Пример онлайн-валидатора JSON-схемы
6. Конвертер JSON-схемы на разные языки

⏯ Видео
1. JSON за 5 минут
2. Формат JSON. От основ к практике
3. Полный курс по JSON для начинающих
4. Валидация JSON в Postman

#проектирование #api

CAP-теорема

CAP-теорема – это утверждение о том, что в любой распределенной системе можно обеспечить выполнение только 2-х из 3-х следующих свойств:

1️⃣ Consistency (согласованность) – все узлы распределенной системы содержат актуальные и одинаковые данные в любой момент времени. Это свойство гарантирует, что любой запрос к системе вернет правильный и последний результат, независимо от того, к какому узлу он обращается.

2️⃣ Availability (доступность) – каждый запрос к системе возвращает результат. Без гарантий, что результат содержит последние данные. Даже если какие-то узлы выпали, система всё равно должна вернуть ответ.

3️⃣ Partition tolerance (устойчивость к разделению) – система продолжает работать даже при потере коммуникации между узлами. Например, если между двумя узлами отвалилась связь, то они продолжают работать независимо друг от друга.

Варианты сочетания свойств

💫💫 (Consistency + Availability) – все узлы системы имеют одинаковые и актуальные данные, и все запросы получают ответ. Такие системы возможны при поддержке ACID-требований к транзакциям (Атомарность, Согласованность, Изоляция, Долговечность) и абсолютной надежности сети. На практике таких решений почти не существует. Классическим примером CA-системы называют распределённую службу каталогов LDAP, а также реляционные базы данных (PostgreSQL, MySQL, MS SQL Server).

💫💫 (Consistency + Partition tolerance) – все узлы системы имеют одинаковые и актуальные данные, и система продолжает работать, даже если между узлами потеряно соединение. Однако, эти системы могут не отвечать на некоторые запросы. Устойчивость к разделению требует дублирования изменений во всех узлах системы.

Как это работает: система CP отрабатывает транзакцию только в том случае, если изменения удалось распространить по всем узлам. Система продолжает обрабатывать запросы даже при отказе одного из узлов. Но пока система не убедится в своей целостности и согласованности, запросы могут не обрабатываться или обрабатываться с задержкой.
Примеры хранилищ данных: Apache HBase, MongoDB, Redis.

💫💫 (Availability + Partition tolerance) – все запросы получают ответ, и система продолжает работать, даже если между узлами потеряно соединение. Эти системы подходят для обработки данных, когда требуется высокая доступность, но можно претерпеть небольшие расхождения в данных. AP-система может быть представлена кластером из нескольких узлов, каждый из которых может принимать данные, но не обязуется в тот же момент распространять их на другие сервера. Такая система отлично справляется с отказами нескольких узлов, но возможна выдача пользователям старых данных. К AP-системам относят CoucheDB, Cassandra, Amazon DynamoDB.

Так как де-факто в распределённых системах сеть может пропадать, соответственно, приходится поддерживать устойчивость к разделению (P). Остаётся пойти на компромисс между согласованностью (C) и доступностью (A).

Применимость CAP-теоремы

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

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

📎 Статьи по теме
1. CAP-теорема: принципы согласованности, доступности и устойчивости
2. CAP-теорема простым, доступным языком
3. Несколько фактов о CAP-«теореме»
4. CAP двенадцать лет спустя: как изменились «правила»
5. Всё, что вы не знали о CAP теореме
6. Мифы о CAP теореме

#проектирование


➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

Паттерны CQRS и Event Sourcing в микросервисной архитектуре

CQRS (Command and Query Responsibility Segregation) — это паттерн, который предлагает разделить операции чтения и записи на отдельные типы операций: Query (запросы) и Command (команды).

Query — операция, которая возвращает данные из хранилища, но не изменяют его. В HTTP Query соответствует метод GET.

Command — операция, которая изменяет состояние хранилища, но не возвращают данные. В HTTP Commands соответствуют методы POST/PUT/PATCH/DELETE.

Event Sourcing — паттерн хранения данных в виде последовательности событий. Идея в том, чтобы записывать в БД каждое событие, которое меняет состояние какой-либо сущности.

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

Как CQRS и Event Sourcing работают вместе?

Организуем два хранилища данных:
💩Первое – первоисточник данных. Используется в командах
💩Второе – оптимизированное для чтения хранилище. Данные сюда сохраняются после выполнения команд.

Процесс при выполнении команд:
1. Микросервис получает команду, проверяет её валидность
2. Если команда валидна, микросервис выполняет команду и генерирует событие
3. Микросервис сохраняет событие в хранилище-первоисточник
4. Микросервис публикует событие в очередь сообщений, где его могут подписаться другие микросервисы
5. Каждый микросервис, который подписан на это событие, обновляет свое хранилище для чтения, применяя событие к своей проекции данных.
6. В хранилище для чтения получаем новый слепок состояния первоисточника данных

При обработке запросов
1. Микросервис получает запрос, который должен вернуть данные из системы.
2. Микросервис обращается к своему хранилищу для чтения (event source), и возвращает данные, не обращаясь к хранилищу для записи.

✅ Преимущества CQRS и Event Sourcing

💩Независимое масштабирование. CQRS позволяет раздельно масштабировать нагрузки чтения и записи, снижая риски конфликтов
💩Оптимизированные схемы данных. Для query можно применить схему, оптимизированную для запросов, а для command — другую схему, оптимизированную для изменений
💩Безопасность. Разделение операций позволяет настроить более гибкую систему доступа.
💩Восстановление состояния. С помощью Event Sourcing можно восстановить состояние системы на любой момент времени, откатить ошибочные операции или исправить поврежденные данные.

⛔️ Недостатки

💩Сложность. Несмотря на простоту идеи, реализация CQRS + Event Sourcing может привести к усложнению проекта приложения, особенно если реализовывать его в связке с другими паттернами, такими как Domain-Driven Design, Saga, Eventual Consistency и т.д.
💩Несогласованность данных. Из-за асинхронной природы обмена сообщениями, данные в хранилищах для чтения и записи могут быть не согласованы на некоторое время.
💩Сложнее тестирование и отладка

📎 Статьи
1. Паттерны CQRS и Event Sourcing
2. Погружение в CQRS
3. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS: часть 1 и часть 2
4. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS
5. Сможет ли Event Sourcing перерасти базы данных?

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

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу

🆚 Сравнение JSON, XML и YAML

JSON, XML и YAML — это языки сериализации данных, то есть способы представления структурированных данных в виде текста. Сериализация данных позволяет обмениваться данными по API и не только, а также часто используется в качестве описания параметров конфигураций.

➖JSON часто используется в веб-разработке и API благодаря простоте и эффективности парсинга.

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

➖YAML менее популярен, но предпочтителен для конфигурационных файлов и удобочитаемых данных благодаря простоте и читаемости. На нём, кстати, составляется разметка Swagger для документации REST API.

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

В комментариях таблица без сжатия

#сравнение

🐳 Docker: Краткое описание и подборка материалов

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

Основные понятия

💩Контейнер — изолированная среда, в которой запускаются приложения вместе со всеми зависимостями, включая библиотеки и компоненты, необходимые для работы приложения.
💩Image (образ) — шаблон для создания контейнера, описывающий, что именно должно быть в контейнере. Образы можно создавать самостоятельно или загружать из репозиториев, таких как Docker Hub.
💩Dockerfile — текстовый файл с инструкцией для создания образа (что должно находиться в образе, какие команды, зависимости и процессы он будет содержать)
💩Registry (реестр/репозиторий) —удалённое (открытое / закрытое) хранилище образов. Docker Hub – публичное хранилище образов.
💩Host — ОС, на которой работает Docker.
💩Platform — программа, которая упаковывает и запускает приложения в контейнере. Собирает код и зависимости
💩Volumes — хранилище данных для приложения.
💩Docker Compose — инструмент для определения и запуска многоконтейнерных приложений с помощью YAML-файла. Docker Compose позволяет настроить параметры, такие как имя сервиса, образ, порты, тома, сети и зависимости между сервисами.
💩Docker Swarm — режим работы Docker, в котором несколько хостов объединяются в кластер для управления и масштабирования контейнеров. Docker Swarm обеспечивает высокую доступность, балансировку нагрузки и обнаружение сервисов.

Архитектура Docker
Docker построен на клиент-серверной архитектуре. Docker-Client общается с Docker-Daemon, который создает, запускает, распределяет контейнеры. Клиент и сервер могут работать как на одной машине, так и удаленно. Интерфейс общения: Socket или REST API.

✏️ Примеры использования

➖Работа с веб-приложением. К примеру, веб-приложение на PHP и нужно его запустить на своем компьютере. Вместо того, чтобы устанавливать PHP, веб-сервер и др. зависимости напрямую, можно использовать Docker для создания контейнера, в который упаковывается всё необходимое для работы веб-приложения.
Далее этот контейнер запускается на вашем компьютере и веб-приложение работает в изолированной среде, не требуя установки всех компонентов на операционной системе.

➖Контейнеризация БД. Например, компания использует БД MongoDB для хранения данных. Чтобы облегчить управление и развертывание, администратор использует Docker для создания контейнера с MongoDB. Этот контейнер содержит необходимую версию MongoDB и все конфигурационные файлы. Это позволяет легко масштабировать, резервировать и обновлять базу данных с минимальными усилиями, а также обеспечивает изоляцию от других приложений и сервисов.

➖Работа с микросервисами. Например, есть веб-приложение, состоящее из нескольких микросервисов: сервис авторизации, обработки заказов и управления пользователями.
Каждый микросервис может быть упакован в свой собственный Docker-контейнер:
один с Node.js для авторизации, другой с Python для обработки заказов и так далее.
Это облегчает масштабирование и управление каждым сервисом независимо.

✅ Преимущества

▫️Изоляция и безопасность: Docker помогает создавать изолированные среды для разработки и тестирования ПО без влияния на основную систему. Например, перенести приложение со всеми зависимостями на другую систему с помощью пары команд в терминале.

▫️Ускорение разработки: Docker позволяет быстро создавать и уничтожать контейнеры. Разработчики могут работать над приложением независимо от ОС

▫️Масштабируемость и отказоустойчивость: позволяет запускать одно приложение в нескольких контейнерах для повышения производительности. Для масштабирования используются платформы оркестрации: OpenShift, Kubernetes, Docker Swarm, Nomad, и тд

⛔️ Недостатки

◾️Повышенная потребность в вычислительных ресурсах
◾️Необходимость оркестрации для крупных приложений
◾️Сложности на Windows и macOS (так как изначально разработан для Linux)

Подборка материалов в следующем посте 👇

#инструменты

Подборка материалов по изучению Docker

Теория по Docker доступна в предыдущем посте.

🌐 Официальная документация Docker

📎 Статьи
1. О Докер с примером на пицце + серия статей
2. Кратко про Docker
3. Термины и концепции.
4. Как работает Docker
5. Подробнее о компонентах
6. Руководство по Docker: с нуля до кластера на AWS — для тех, кто хочет попробовать сам
7. Всегда ли нужны Docker, микросервисы и реактивное программирование?
8. Руководство по Docker Compose для начинающих
9. Про Docker Swarm

⏯ Видео
1. Пример. Экосистема контейнеров в Yandex.Cloud
2. Зачем нужен и как работает Docker
3. Практический курс Docker и Kubernetes
4. Коротко о Docker
5. Docker образы. Микросервисы — Демо-занятие курса «DevOps практики и инструменты»
6. Курс по Docker

🕸 Kubernetes: Краткое описание и подборка материалов

Сначала рекомендуем изучить пост про Docker

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

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

Основные понятия

💩Узел (node) – физическая или виртуальная машина, на которой запускаются поды.
💩Под (pod) – группа контейнеров с общими разделами, запускаемых как единое целое. Минимальная единица развёртывания в Kubernetes.
💩Сервис (service) – абстракция, которая определяет политику доступа к подам. Сервис балансирует трафик между подами и предоставляет единую точку входа для клиентов.
💩Replication Controllers – контроллер, который гарантирует, что определенное количество реплик (копий) пода будут запущены в любой момент времени.
💩Раздел (Volume) – директория, которая доступна в контейнере.
💩Лейблы (Labels) – пары ключ-значение которые прикрепляются к объектам, например, к подам.

Главные функции K8s

1️⃣ Централизованное управление (оркестровка) контейнерами. Kubernetes автоматически управляет жизненным циклом контейнеров от развёртывания до откатов обновлений.

2️⃣ Распределение нагрузки и масштабирование кластера. Kubernetes распределяет контейнеры по узлам так, чтобы они не тратили лишние ресурсы. Если нагрузка на систему растёт, Kubernetes может автоматически добавлять контейнеры и узлы.

3️⃣ Управление конфигурациями. В Kubernetes есть средство для центрального управления конфигурациями — ConfigsMaps для настроек и Secrets для конфиденциальных данных. Если разместить в них свои настройки, то приложения смогут получить к ним доступ из любого узла.

Kubernetes 🆚 Docker

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

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

Ещё есть Docker Swarm — встроенный в докер инструмент оркестровки контейнеров. Его как как раз и можно полноценно сравнивать с Kubernetes.

✅ Преимущества Kubernetes

▫️Масштабируемость. Kubernetes позволяет горизонтально масштабировать приложения, добавляя или удаляя поды в зависимости от нагрузки. Kubernetes также поддерживает вертикальное масштабирование, изменяя выделенные ресурсы для подов.

▫️Надежность. Kubernetes обеспечивает высокую доступность приложений, перезапуская поды в случае сбоя. Kubernetes поддерживает стратегии бесперебойного обновления, которые позволяют внедрять новые версии приложений без простоя.

▫️Эффективность. Kubernetes позволяет оптимально распределять поды по доступным узлам. Kubernetes автоматически управляет ресурсами и позволяет задавать ограничения и приоритеты для подов.

⛔️ Недостатки Kubernetes

◾️Сложность. Kubernetes сложно изучать, настраивать и поддерживать, требуются дополнительные инструменты и процессы для работы приложений.

◾️Необходимость адаптации приложений. Kubernetes требует, чтобы приложения соответствовали определенным правилам и практикам. Это может потребовать изменения или создания приложений с нуля.

◾️Высокие требования к ресурсам. Kubernetes занимает много ресурсов. Это может снизить производительность или увеличить стоимость приложений.

Подборка материалов в следующем посте👇

#инструменты

🕸 Подборка материалов по Kubernetes

Конспект по Kubernetes доступен в предыдущем посте.

🌐 Официальная документация

🔹 Наши посты
1. Про Docker
2. Виртуализация, контейнеризация и оркестрация

🗒 Статьи (теория)
1. Кратко о Kubernetes
2. Kubernetes — основные понятия
3. Про возможности Kubernetes в сравнении с Docker
4. Подробнее про компоненты Kubernetes
5. Внутреннее устройство Kubernetes-кластера простым языком
6. Kubernetes: большой обзор технологии, установка и настройка
7. Docker Swarm vs Kubernetes

📝 Практика
1. Инструкция по установке и настройке Kubernetes на Ubuntu
2. Подробный гайд для новичков по установке Kubernetes
3. Попробовать потыкать Kubernetes на тестовом кластере
4. Визуальное руководство по диагностике неисправностей в Kubernetes
5. Шеринг GPU в Kubernetes с помощью MIG и TimeSlicing
6. Гайд по запуску приложений с высокой доступностью (HA) в Kubernetes
7. 10 типичных ошибок при использовании Kubernetes

💼 Кейсы по компаниям из цикла статей на Хабре
1. 4200 подов и TessMaster у eBay
2. Concur и SAP
3. GitHub
4. SoundCloud
5. Цифровой банк Monzo
6. BlaBlaCar
7. BlackRock
8. Huawei
9. ЦЕРН и 210 кластеров K8s
10. Reddit

⏯ Видео
1. Курс по Kubernetes с нуля
2. Что такое Kubernetes за 9 минут
3. 49 видеоуроков по Kubernetes
4. Открытая вечерняя школа. Kubernetes для разработчиков
5. Практика по Kubernetes — серия уроков

📚 Подборка книг для развития системного аналитика

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

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

Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО
📖 Халл Элизабет. Инженерия требований
📖 Юрий Химонин. Сбор и анализ требований к программному продукту

Архитектура и проектирование
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования (DDD)
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Беллемар Адам. Создание событийно-управляемых микросервисов
📕 C. Cомасегар. Руководство Microsoft по проектированию архитектуры приложений

Проектирование
📒 Александр Швец. Погружение в Паттерны Проектирования
📒 System Design. Подготовка к сложному интервью
📒 Мартин Фаулер. P of EAA: Шаблоны корпоративных приложений

Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Джей Гивакс. Паттерны проектирования API
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API
📗 Дилан Скотт. Kafka в действии
📗 Ian Robinson. REST in Practice: Hypermedia and Systems Architecture
📗 Emil Koutanov. Effective Kafka

Своды знаний
📔 SEBoK — Systems Engineering Body of Knowledge
📔 BABOK — Business Analysis Body Of Knowledge
📔 INCOSE Guide for Writing Requirements
📔 DAMA-DMBOK — Data Management Body of Knowledge

Навыки
📓 Ф.П. Тарасенко. Прикладной системный анализ
📓 Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
📓 Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы

UML
💣 Мартин Фаулер. UML. Основы
💣 Буч Грэди. Язык UML. Руководство пользователя
💣 Дж. Шмуллер. Освой самостоятельно UML за 24 часа
💣 Крэг Ларман. Применение UML и шаблонов проектирования
💣 Джим Арлоу. UML 2 и Унифицированный процесс
💣 М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка
💣 Александр Леоненков. Самоучитель UML

Python
🐍 Эрик Мэтиз. Изучаем Python: программирование игр, визуализация данных, веб-приложения
🐍 Пол Бэрри. Изучаем программирование на Python
🐍 Эл Свейгарт. Автоматизация рутинных задач с помощью Python
🐍 Марк Лутц. Python. Карманный справочник
🐍 Аллен Б. Дауни. Основы Python. Научитесь думать как программист

Эта навигация будет дополняться в Библиотеке Системного Аналитика

#подборка

Подписка на закрытый канал для системных аналитиков

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

Оформить подписку можно через кнопки ниже:
1. Нажимаете на кнопку с выбранным тарифом
2. Бот Donate присылает ссылку на оплату
3. После оплаты вам будет предоставлен доступ к закрытому каналу. Ссылки на чаптер системных аналитиков и канал с тестовыми заданиями будут в описании закрытого канала.

Что будет входить в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес)

Что будет с текущим каналом?
Все уже опубликованные материалы в текущем канале (Системный Аналитик) останутся бесплатными. Однако новые материалы будут выходить реже:
— 2-3 полноценные подборки в месяц
— 1-2 конспекта по темам системного анализа еженедельно
— 1 книга каждую неделю

Текущие цены действуют для первых 50-ти подписчиков.