🏗 Пост: CQRS: КОГДА ЧИТАТЬ И ПИСАТЬ НУЖНО ПО-РАЗНОМУ

Привет, коллеги! 👋 Бывает: в одной системе есть и оперативные запросы (должны быть быстрыми), и аналитические (тяжёлые, с агрегатами). Если их смешать, страдают и те, и другие. Выход — CQRS (Command Query Responsibility Segregation). Разбираем на реальном кейсе. ⚙️

📌 Кейс: «Аналитика тормозит интерфейс»

В CRM для менеджеров отчёты по продажами грузились 10 секунд, а список клиентов открывался мгновенно. Проблема: отчёты делали тяжёлые GROUP BY по той же таблице, блокируя индексы. Менеджеры жаловались, продажи падали.

Что сделал архитектор?
Разделил команды (запись) и запросы (чтение). Команды идут в нормализованную БД (OLTP), запросы — в денормализованную read-модель (Redis + материализованные представления). Изменения из командной модели асинхронно проецируются в read-модель через Kafka.

Как выглядит код проекции (упрощённо):

# Слушаем события из Kafka
for event in kafka.consumer():
    if event.type == "ORDER_CREATED":
        # Денормализуем: считаем агрегаты и сохраняем в Redis
        redis.hincrby(f"sales:{event.date}", "total", event.amount)
        redis.hincrby(f"sales:{event.date}", "count", 1)

Что дал CQRS:

Список заказов (команды) — < 50 мс.
Отчёт по продажам (запрос) — 200 мс (вместо 10 секунд).
База под команды не страдает от сложных выборок.

📌 Что должен зафиксировать аналитик

Разделить потоки записи и чтения в архитектуре.
Допустимость eventual consistency (задержка между записью и чтением до 5 секунд).
Выбрать хранилище для read-модели (Redis, Elasticsearch, реплика).
Описать события, на которые подписываются проекторы.

Вывод: CQRS — мощный паттерн, когда у вас разные требования к скорости записи и чтения. Аналитик, понимающий CQRS, может предложить его для развязки нагрузки и спасения производительности. 🎯

#ARCHITECTURE

⭐️Интеграции: Кровеносная система вашего IT-продукта

💼Представьте, что вы построили двигатель Ferrari, но забыли подключить его к колесам. Шума много, толку — ноль.
📚В мире IT интеграция — это именно то, что заставляет бизнес ехать, а не просто рычать на холостых оборотах.
🗂Для Системного Аналитика (SA) интеграция — это не просто «стрелочка» на диаграмме. Это искусство договориться двум системам, которые часто говорят на разных языках, имеют разную логику и находятся в разных часовых поясах.
Если приложение не умеет общаться с внешним миром (банками, CRM, AI-сервисами), оно бесполезно для бизнеса.
‼️Вот 3 кита, на которых держится качественная проработка интеграций (сохраняйте, чтобы не потерять!):

1️⃣Выбор паттерна: Синхрон vs Асинхрон ⚡️ Не пытайтесь везде впихнуть REST API.
Нужен мгновенный ответ пользователю (например, логин на сайте)? Используем REST/gRPC (Синхрон).
Нужно отправить тяжелый отчет или обработать миллион транзакций без зависания интерфейса? Зовите брокеров сообщений (Kafka, RabbitMQ). Асинхронность — это про масштабируемость и отказоустойчивость.

2️⃣Контракт — это закон «Потом договоримся» — фраза, убившая тысячи проектов. Начинайте с API First.
Сначала пишем спецификацию (OpenAPI/Swagger), утверждаем поля, типы данных и обязательность, и только потом разработчики пишут код. Нет контракта — нет интеграции.

3️⃣Думайте об ошибках, а не об успехе 🛡 Happy Path (счастливый сценарий) нарисует и джун. Профи думает о том, что будет, если:
Сервис-получатель упал? (Нужны Retry-политики).
Запрос ушел, а ответ не пришел? (Привет, таймауты).
Пользователь нажал кнопку «Оплатить» дважды? (Здесь нужна идемпотентность).

💡AI-инсайт: Сегодня интеграции выходят на новый уровень. Мы больше не просто перекладываем JSON-ы.
📨Мы встраиваем AI-агентов, которые анализируют потоки данных в реальном времени. Грамотная архитектура интеграции сейчас — это фундамент для внедрения Искусственного 📨Интеллекта завтра.

❗️❗️❗️
Итог: Хороший аналитик знает, как передать данные. Отличный аналитик знает, почему именно так, и что делать, если все сломается.

#INTEGRATION

🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤 🔤 🔤🔤🔤🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤🔤 🔤🔤🔤 ➖ 🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤🔤🔤🔤🔤❗️❗️❗️

Представьте: CRM система 📋 и складская система 🏭 «договорились» обмениваться данными о заказах. На совещании всё понятно. Но когда дело доходит до кода — начинается хаос 🤯.

📌 ПРОБЛЕМА «УСТНЫХ ДОГОВОРЕННОСТЕЙ 🎤 → 💥
• «Поле userName или username?» 🤔
• «Сумма заказа — целое число или с копейками?» 💰
• «Дата в UTC или в местном времени?» 🕐
• «status: "active" или "enabled"?» 🔄

Эти мелкие нестыковки ломают интеграции в production 💥. Системный аналитик здесь — не просто посредник, а *архитектор коммуникации* 🏗, который формализует диалог систем в виде исполняемого контракта 📜.

💡 КЛЮЧЕВАЯ МЫСЛЬ. В современной разработке; КОД — это и есть самая точная документация 📖 → 💻. Поэтому лучший способ согласовать интеграцию — начать с написания её формального описания на специальном 'языке контрактов' ✍️.

🎯 ДЛЯ ЧЕГО ЭТО НУЖНО АНАЛИТИКУ 🎓:
1️⃣ Устранить неоднозначность требований ✅
2️⃣ Позволить командам работать параллельно 🚀
3️⃣ Обнаруживать breaking changes до деплоя 🔍
4️⃣ Автоматически генерировать клиентские библиотеки ⚙️

🛠 ПРАКТИЧЕСКИЙ ИНСТРУМЕНТАРИЙ🧰:
• 📊 OpenAPI/Swagger — для REST API
• 🔄 AsyncAPI — для событийных шин (Kafka, RabbitMQ)
• 🕸 GraphQL Schema — для гибких запросов
• ⚡️ Protobuf/gRPC — для высокопроизводительных RPC

📋 ПРОСТОЙ ПРИМЕР: как выглядит «договор» между системой заказов 🛒 и системой доставки 🚚:

# 📜 Контракт на создание заказа (OrderCreated.event.yaml)
event: OrderCreated
version: 1.0.0
description: 🎉 Заказ успешно создан и оплачен 💳

payload:
  type: object
  required: 📌
    - orderId
    - customerId
    - items
    - totalAmount
  properties:
    orderId:
      type: string
      format: uuid
      example: "550e8400-e29b-41d4-a716-446655440000" 🆔
    customerId:
      type: string
      format: uuid 👤
    items:
      type: array
      minItems: 1 📦
      items:
        type: object
        properties:
          productId: { type: string } 🏷
          quantity: { type: integer, minimum: 1 } 🔢
          price: { type: number, minimum: 0 } 💵
    totalAmount:
      type: number
      minimum: 0
      exclusiveMinimum: true 💰
    currency:
      type: string
      pattern: '^[A-Z]{3}$'
      default: "RUB" ₽
    createdAt:
      type: string
      format: date-time
      description: "⏰ Время в формате ISO 8601 (UTC)"

🔍 ПОЧЕМУ ИМЕННО ФОРМАЛЬНЫЙ КОНТРАКТ, А НЕ ДОКУМЕНТ В CONFLUENCE? 📄❌

1️⃣ 🤖 МАШИНОЧИТАЕМОСТЬ:
• Можно автоматически сгенерировать код на Java ☕️, Python 🐍, C# ⚡️
• Можно провести валидацию данных в рантайме ✅
• Можно создать mock-сервер для тестирования 🧪

2️⃣ ✅ ВЕРИФИЦИРУЕМОСТЬ:
Если система-потребитель ожидает поле deliveryAddress 🏠, а система-источник его не отправляет — тест упадёт на этапе CI/CD 🔧, а не в production 💥.

3️⃣ 🔄 ЭВОЛЮЦИОННОСТЬ:
Версии контракта позволяют плавно мигрировать. Можно добавить новое поле discountAmount 🎁, не ломая старых потребителей.

🎭 РОЛЬ СИСТЕМНОГО АНАЛИТИКА В ЭТОМ ПРОЦЕССЕ 👨💼 → 🏗:

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

1️⃣ 🎯 Выявить ключевые сущности и их атрибуты
2️⃣ 📝 Определить обязательные и опциональные поля
3️⃣ ⚙️ Установить форматы данных (даты 📅, валюты 💱, идентификаторы 🆔)
4️⃣ 🚨 Спроектировать сценарии ошибок и их обработки
5️⃣ 🔮 Предусмотреть будущие расширения

📈 КОНКРЕТНЫЙ РЕЗУЛЬТАТ ДЛЯ БИЗНЕСА 📊:

• ⏱️ Сокращение времени на интеграцию на 30-40%
• 🛡 Уменьшение инцидентов в production на 60-70%
• 🔌 Возможность быстрого подключения новых систем
• 🔍 Прозрачность взаимодействия между командами

💎 🔤🔤🔤🔤🔤🔤🔤
В мире микросервисов и распределённых систем 🌐, интеграция — это не «подключили и забыли» 🔌. Это постоянный диалог 🗣, где код выступает в роли формального протокола 📜.

Системный аналитик, который умеет проектировать эти протоколы 🏗, становится ключевым звеном 🔑 в создании устойчивых, масштабируемых и понятных IT-ландшафтов 🏙.

#INTEGRATION

🧩 🔤🔤🔤🔤🔤🔤 🔤🔤🔤— это ваш навигатор в проекте

Умение писать и читать SQL-запросы даёт вам, как аналитику, три ключевых преимущества:

Глубокое понимание «анатомии» системы. Вы видите, как данные связаны между собой, и можете предсказать, где возникнут проблемы при масштабировании.
Проверка требований на реализуемость. Можно сразу набросать структуру будущих таблиц и выявить противоречия в требованиях до этапа разработки.
Предотвращение архитектурных ошибок. Помогает оценить, как сегодняшнее решение повлияет на завтрашние возможности системы. Часто проще потратить день на проектирование, чем месяцы на исправление «костылей».
💥 Боль из реальных проектов: когда незнание SQL било по срокам

Давайте на примерах. Думаете, я преувеличиваю?

Кейс 1: ФИО одной строкой. В проекте было решено хранить ФИО пользователя в одном поле full_name. Казалось бы, мелочь. Но когда потребовалась интеграция с госсистемой, где ФИО передаются тремя раздельными полями, пришлось:
Писать хрупкий алгоритм разбивки строки (а как быть с двойными фамилиями или отчествами вроде «оглы»?).
Менять API, интерфейсы и все интеграции.
Результат: три месяца незапланированной работы вместо одной маленькой фичи.

Кейс 2: Один владелец на машину. В системе для автосервиса изначально заложили, что у машины один владелец. В жизни же часто бывает два-три совладельца. Пришлось экстренно менять связь в БД с «один-ко-многим» на «многие-ко-многим», что потянуло за собой лавину изменений.
Этих проблем можно было бы избежать, если бы на этапе анализа и проектирования кто-то спросил: «А как эти данные лежат в базе?» и смог проверить это сам.

🛠 Ваш базовый арсенал: SQL-запросы, которые стоит освоить в первую очередь

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

🚀 🔤🔤🔤 🔤🔤🔤🔤🔤🔤❓

1. SELECT и WHERE: Видеть и фильтровать
Базовый запрос — ваш главный инструмент изучения данных.

sql
-- Выбрать всех активных пользователей из Москвы, зарегистрированных после 2023 года
SELECT first_name, last_name, email
FROM customers
WHERE city = 'Москва'
AND registration_date >= '2023-01-01'
AND status = 'active';
2. JOIN: Связывать сущности
Суть реляционных баз — в связях. JOIN помогает их восстановить.

sql
-- Узнать, какие товары и в каком количестве заказал каждый клиент
SELECT c.first_name, c.last_name, p.product_name, oi.quantity
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id;
3. GROUP BY и агрегатные функции: Считать и обобщать
Для анализа и отчетов без этого никуда.

-- Посчитать выручку и средний чек по каждому городу
SELECT 
    c.city,
    COUNT(o.order_id) as total_orders, -- количество заказов
    SUM(o.total_amount) as total_revenue, -- общая выручка
    AVG(o.total_amount) as avg_order_value -- средний чек
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.city;

4. Подзапросы и CTE (WITH): Декомпозировать сложные вопросы
Когда запрос становится слишком сложным, его нужно разбить на части.

-- Найти клиентов, которые делали заказы на сумму больше средней
WITH avg_order_value AS ( -- CTE: вычисляем средний чек один раз
    SELECT AVG(total_amount) as avg_amount FROM orders
)
SELECT c.first_name, c.last_name, o.total_amount
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.total_amount > (SELECT avg_amount FROM avg_order_value);

5. Оконные функции (OVER): Анализировать в контексте
Мощный инструмент для скользящих сумм, ранжирования и сравнений без потери детализации.

-- Для каждого заказа показать сумму заказа и общую сумму всех заказов его клиента
SELECT 
    o.order_id,
    o.customer_id,
    o.total_amount,
    SUM(o.total_amount) OVER (PARTITION BY o.customer_id) as customer_lifetime_value
FROM orders o;

#SQL

🔍 ТЕСТИРОВАНИЕ ДЛЯ АНАЛИТИКА: КОД, КЕЙСЫ, ИНСАЙТЫ

Привет, коллеги! 👋 Хороший аналитик не просто пишет требования, но и участвует в тестировании. Почему? Потому что именно вы знаете, как система должна работать на самом деле. Сегодня покажу на реальных кейсах с примерами кода, как аналитик может помочь QA и разработке находить баги до продакшена. 🚀

📌 Кейс 1: Интеграция и ретраи (код на Python)

Ситуация: Платежный шлюз иногда возвращает 503 (сервис временно недоступен). В требованиях написано: «При ошибке повторить запрос». Разработчик сделал один повтор через 1 секунду.

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

```python
import requests
import time

def test_payment_retry():
    url = "https://payment-gateway/api/pay"
    payload = {"order_id": 123, "amount": 1000}
    
    for attempt in range(3):
        response = requests.post(url, json=payload)
        if response.status_code == 503:
            wait_time = 2 ** attempt  # 1, 2, 4 секунды
            print(f"Попытка {attempt+1} не удалась, ждём {wait_time}с")
            time.sleep(wait_time)
        else:
            assert response.status_code == 200
            print("Успех!")
            return
    assert False, "Все попытки исчерпаны"

Результат: Баг нашли на тестовом стенде. В ТЗ добавили экспоненциальную задержку (1, 2, 4 сек) и 3 попытки. 🎯

📌 Кейс 2: Граничные значения (тестируем форму)

Ситуация: В форме заказа есть поле «Количество товаров» от 1 до 999. Разработчик сделал валидацию, но пропустил ноль и отрицательные числа.

Что сделал аналитик: Написал параметризованный тест на Python с библиотекой pytest:

import pytest

def validate_quantity(q):
    return 1 <= q <= 999

@pytest.mark.parametrize("input,expected", [
    (0, False),      # граница снизу
    (1, True),       # минимальное допустимое
    (500, True),     # среднее значение
    (999, True),     # максимальное допустимое
    (1000, False),   # граница сверху
    (-5, False),     # отрицательное
    ("abc", False)   # не число
])
def test_quantity_validation(input, expected):
    assert validate_quantity(input) == expected

Результат: Тест показал, что 0 и отрицательные числа пропускаются. Разработчик исправил валидацию до выкладки. ✅

📌 Кейс 3: Регрессия (автотест на проверку баланса)

Ситуация: Добавили новую фичу — скидки постоянным клиентам. Нужно убедиться, что старый функционал (списание баланса) не сломался.

Что сделал аналитик: Простой скрипт для smoke-теста:

def test_balance_after_purchase():
    # Данные тестового пользователя
    user_id = 999
    initial_balance = get_balance(user_id)  # предположим, 1000
    
    # Покупаем товар за 300
    purchase(user_id, 300)
    
    # Проверяем новый баланс
    new_balance = get_balance(user_id)
    expected = initial_balance - 300
    
    assert new_balance == expected, f"Ожидалось {expected}, получено {new_balance}"
    print("Баланс обновился корректно")

Результат: Запускаем перед каждым релизом — спим спокойно. 😴

📌 Инструменты для аналитика

Postman — коллекции с автотестами для API (проверка статусов, схем ответа).
Python + requests — быстрые скрипты для сложных сценариев.
pytest — параметризация, фикстуры, отчёты.
Gherkin (Cucumber) — сценарии на понятном бизнесу языке:

Feature: Бонусы за регистрацию
  Scenario: Новый пользователь получает 500 бонусов
    Given пользователь не зарегистрирован
    When он регистрируется с телефоном "+79991234567"
    Then его бонусный счёт равен 500

🎯 ИТОГ: ЧТО ДЕЛАТЬ АНАЛИТИКУ?

Писать проверяемые требования — с цифрами, диапазонами, примерами.
Готовить тестовые сценарии — включая негативные и граничные.
Автоматизировать рутину — простые скрипты экономят часы ручных проверок.
Участвовать в код-ревью тестов — подсказывать QA, какие кейсы важны.
Помните: Баг, найденный на этапе анализа или тестирования, стоит в 10 раз дешевле, чем на проде. Аналитик с навыками тестирования — золото для команды. 💰

#TESTING

⁉️ Устал искать интересные каналы про Искусственный интеллект?

📁 СОХРАНИ СЕБЕ ЧТОБЫ НЕ ПОТЕРЯТЬ

В этой папке собраны каналы по ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.

😏 ЗАБИРАЙ ПАПКУ ТУТ

⏰ Папка действует 72 часа.

🤩 Организаторы: Green.Papka