Архитектура ПО

зачем это зачем аналитику знать, что такое архитектура

карта раздела одна история, шестнадцать глав

Главы идут по порядку: каждая опирается на предыдущую. Нажмите на главу, чтобы перейти к ней. Если времени мало — прочитайте главы 1, 4, 7, 9 и 14: это скелет раздела.

зачем это зачем разбирать живые системы

игра «Кафе растёт»: пройдите путь от ларька до сети

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

переводчик умное слово → что это на самом деле

Нажмите на карточку — увидите, что это значит «на человеческом». Это не упрощение ради упрощения: если вы не можете объяснить термин через кафе или почту, вы его пока не понимаете.

задание угадайте термин по описанию

Описание бытовое — термин архитектурный. Решено 0 из 0.

зачем это зачем вообще начинать с монолита

карта раздела один год одного монолита, двенадцать глав

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

зачем это зачем нужен модульный монолит

зачем он нужен что именно болит в обычном монолите

Прежде чем разбираться в устройстве — зачем вообще этот переход. Четыре боли, из-за которых наводят модули. Нажмите на любую: слева будет «как сейчас», справа «как станет».

анатомия из чего он состоит: нажмите на любую часть

Прежде чем разбираться, как он работает, посмотрим, из чего он сделан. Нажимайте на части схемы — под ней появится объяснение.

словарь модуля что за звери: фасад, DTO, событие, сущность

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

с самого начала чем он отличается от обычного монолита

Коротко: всеми тремя признаками монолита он остаётся. Одна сборка, один запуск, одна база. Меняется только одно — что происходит внутри.

три слова фасад, граф и цикл — что это вообще такое

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

правила четыре правила, которые делают монолит модульным

Всё остальное — детали. Если выполняются эти четыре, вынести модуль в отдельный сервис позже — это вопрос недели: заменить вызов метода на HTTP-клиент за тем же интерфейсом.

принцип по какому правилу вообще раскладывать код

Один и тот же код можно разложить по папкам двумя способами. Файлы те же самые — разная только группировка. Нажмите на задачу и посмотрите, какие файлы придётся открыть.

алгоритм как разложить свою систему: шесть шагов

Работает и для нового проекта, и для наведения порядка в существующем. Делайте по порядку, шаги опираются друг на друга.

структура по слоям или по фичам

Одни и те же классы можно разложить двумя способами. Слева — привычная нарезка по техническим слоям, справа — по бизнес-возможностям. Разница не косметическая: во втором случае у модуля есть граница, и её можно защитить.

// «Заказы» размазаны по четырём пакетам.
// Чтобы вынести заказы, надо собрать их по всей базе кода.
com.shop
├── controller/
│     OrderController, PaymentController, CatalogController
├── service/
│     OrderService, PaymentService, CatalogService
├── repository/
│     OrderRepo, PaymentRepo, CatalogRepo
└── model/
      Order, Payment, Product   ← общие для всех

// Ничто не мешает написать:
class OrderService {
  private final PaymentRepo paymentRepo;  // чужой репозиторий
  void pay(Long id){
    paymentRepo.insertDirect(...);        // мимо чужой логики
  }
}

// Модуль целиком в одном пакете. Наружу торчит
// только api/, всё остальное — internal/.
com.shop
├── order/
│     api/      OrderFacade, OrderDto, OrderPlaced
│     internal/ OrderService, OrderRepo, Order
├── payment/
│     api/      PaymentFacade, PaymentDto
│     internal/ PaymentService, PaymentRepo
└── catalog/
      api/      CatalogFacade, ProductDto
      internal/ ...

// Единственный законный способ:
class OrderService {
  private final PaymentFacade payments;   // контракт
  void pay(Long id){
    payments.charge(new ChargeCmd(id, sum)); // его правила
  }
}

попробуйте сами что такое «стена» на самом деле

Вы пишете код в модуле «Заказы». Вам нужны данные о клиенте. Нажмите на каждый способ и посмотрите, что скажет сборка.

интерактив страж границ: какие зависимости пропустить в сборку

Ниже — реальные зависимости, которые люди пытаются добавить в код. Ваша задача — решить, пропустить или отклонить. Так же работает автоматическая проверка (ArchUnit, Spring Modulith, jQAssistant, deptrac): правило описано в тесте, и сборка падает на нарушении, ещё до ревью.

Разобрано 0 из 0.

А вот как это выглядит в виде теста

// ArchUnit: правило живёт в коде и падает в CI, а не в голове тимлида
@ArchTest
static final ArchRule modules_do_not_touch_internals =
    slices().matching("com.shop.(*)..")
            .should().notDependOnEachOther()
            .ignoreDependency(alwaysTrue(), resideIn("..api.."));

@ArchTest
static final ArchRule no_cross_module_repositories =
    noClasses().that().resideInAPackage("..order..")
        .should().dependOnClassesThat().resideInAPackage("..payment.internal..");

// Spring Modulith делает то же самое одной строкой:
@Test void verifiesModularStructure(){
    ApplicationModules.of(ShopApplication.class).verify();
}

попробуйте соберите цикл своими руками

Три модуля. Нажимайте на стрелки — добавляйте и убирайте зависимости. Смотрите, что говорит сборка.

диаграмма как модули разговаривают: посмотрите своими глазами

Клиент оплатил заказ. Модуль «Платежи» должен сообщить об этом модулю «Заказы». Три способа сделать это внутри одного процесса — выберите и прожмите шаги.

механика как модули разговаривают внутри одного процесса

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

эксперимент что будет через полгода

Два одинаковых проекта. В одном проверка границ включена, в другом решили «мы и так аккуратные». Прокрутите время.

баланс модульный монолит честно

задание границы модулей

Решено 0 из 0.

зачем это зачем нужны микросервисы

зачем они нужны что болит в модульном монолите — и что не болит

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

с самого начала что именно меняется

Мы разобрали монолит: одна сборка, один запуск, одна база. Микросервисы — это когда все три признака отключены сразу. У каждой части свой репозиторий, свой процесс и своя база.

Одна и та же строчка кода в трёх мирах

Смотрите, как одна операция — «взять заказ вместе с именем клиента» — меняется при переходе. Переключайте.

чем платим четыре вещи, которые были бесплатными и перестали

Это главное, что нужно понять про микросервисы. Не «они лучше» и не «они хуже» — а вот конкретно что вы теряете. Нажмите на каждую.

проверка три вопроса, отличающие микросервис от куска монолита по сети

интерактив калькулятор цепочки: цена каждого сетевого прыжка

Главный контринтуитивный факт распределённых систем: надёжности перемножаются, а задержки складываются. Один вызов пользователя проходит цепочку сервисов — покрутите ручки и посмотрите, во что превращается «каждый сервис надёжен на 99,9 %».

антипаттерн распределённый монолит — худшее из двух миров

Система выглядит как микросервисы, а ведёт себя как монолит: сложность распределённости уже оплачена, независимость ещё не получена. Нажмите на признак, чтобы увидеть, чем он лечится.

цена налог на микросервисы: что придётся построить до первого сервиса

Это не «желательно», а входной билет. Без этих вещей двадцать сервисов — это двадцать способов сломаться так, что никто не заметит.

размер насколько «микро» — это микро

Правильный ответ на вопрос «сколько строк в микросервисе» — это неправильный вопрос. Размер определяется границей, а не строками. Рабочие ориентиры:

баланс микросервисы честно

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

Решено 0 из 0.

напрямую чем один лучше другого: три пары

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

подбор что нужно именно вам: пять вопросов

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

шкала пять точек, а не две

таблица двенадцать критериев вплотную

Нажмите на строку — раскроется объяснение, почему именно так, и что с этим делать. Столбцы: М — монолит, ММ — модульный монолит, МС — микросервисы.

интерактив выбери под ситуацию

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

Решено 0 из 0.

миграция симптом → минимальный шаг

Таблица «что болит — что делать». Обратите внимание: в большинстве строк ответ не «микросервисы». Самая частая ошибка — лечить организационную или инфраструктурную боль архитектурной операцией на открытом сердце.

главное правило в одну строку для каждого стиля

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

подбор выберите свою ситуацию — получите разбор

Так думают на практике: не «какой стиль лучше», а «у меня вот такая беда, что с ней делать». Нажмите на ситуацию, похожую на вашу.

разбор пятнадцать стилей на одном примере

Чтобы стили не путались, все пятнадцать разобраны на одной и той же компании — магазине кроссовок «Ботинок» из раздела про домены: подбирает размер по фото стопы, торгует, возит, ведёт склад.

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

главное стили не выбирают насмерть, их сочетают

Самая частая ошибка новичка: считать, что надо выбрать один стиль и жить с ним. На практике в одной системе их несколько, и это нормально.

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

Прокрутите вбок, если не помещается. Главная колонка — «связанность». Она объясняет почти все остальные.

тренажёр подберите стиль под ситуацию

Решено 0 из 0.

зачем это зачем раскладывать бизнес на домены

карта раздела одна история, четырнадцать глав

Главы 1–3 — первая встреча Олега с бизнесом и главное различение раздела: проблема против решения. Главы 4–5 — как искать поддомены и как подслушать будущие границы в словах людей. Главы 6–10 — типы поддоменов и деньги: куда вкладывать, что покупать, что бывает, если перепутать. Главы 11–13 — перенос на другой бизнес, путь от поддоменов к границам системы и документы аналитика. Дальше по книге — «Event Storming», «Ограниченные контексты» и «Как резать». Кнопка переносит к главе.

зачем это зачем аналитику и архитектору Event Storming

карта раздела один воркшоп, пятнадцать глав

Главы идут по порядку дня: сначала азбука (что такое событие, какие бывают стикеры), потом подготовка, потом сам воркшоп и то, что из него получается. Самое наглядное — живая стена в главе 6 и ножницы в главе 8: там видно, как из хаоса проступают границы. Кнопка переносит к главе.

зачем это зачем нужны ограниченные контексты

зачем это вообще что за контексты и почему на них режут

Начнём с честного вопроса: зачем вообще что-то резать на «контексты»? Ответ проще, чем кажется, и он не про код.

Житейски: одно слово, разные смыслы

Слово «ключ». В слесарной мастерской это инструмент. В гостинице — то, чем открывают номер. В музыке — знак в начале нотной строки. У программиста — поле, по которому ищут запись.

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

А теперь то же самое в «Ботинке»

Нажмите на каждый отдел — посмотрите, что он имеет в виду под словом «заказ».

Вот теперь — зачем режем

интерактив одно слово — четыре модели

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

различие поддомен и контекст — не синонимы

В идеале один контекст = один поддомен. На практике встречается и другое, и это не всегда ошибка:

• Один поддомен разбит на несколько контекстов — обычно вынужденно: часть уже живёт в legacy-системе, часть в новой. Признак технического долга, но иногда осознанное переходное состояние.
• Один контекст покрывает несколько поддоменов — нормально для мелких поддерживающих кусков, которые не стоят отдельного сервиса. Не плодите сущности без нужды.
• Контекст совпал с покупным продуктом — типично для общих поддоменов: «1С» или платёжный провайдер целиком является контекстом с чужой моделью, и наша задача — изолировать его.

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

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

признаки как понять, что перед вами два контекста, а не один

механика чем контексты связаны, если не общими классами

задание контексты на практике

Решено 0 из 0.

зачем это зачем рисовать карту контекстов

зачем это вообще отношение — это не про код, это про людей

Самое непонятное место во всей теме. Давайте начистоту: отношение между контекстами — это договорённость двух команд о том, кто под кого подстраивается. Всё. Никакой техники.

Вопрос, на который отвечает отношение

Он всего один, и звучит так:

Пока ответа нет, каждое изменение превращается в переговоры с нуля, а иногда и в скандал. Когда ответ записан заранее — это просто рабочая процедура.

Что бывает, когда отношение не названо

на живом примере пять разговоров, которые решает карта контекстов

Тот же магазин «Ботинок». Нажмите на разговор — увидите, какое здесь отношение, что оно значит на практике и что делать дальше.

что делать дальше карта нарисована — и?

Самый честный вопрос: хорошо, повесили схему на стену. Что с ней делают в понедельник?

как выглядит сама карта контекстов — вот она

Сначала о том, что вообще имеется в виду под словом «карта». Это буквально схема на стене: коробки — части системы, стрелки — кто с кем разговаривает, подписи на стрелках — какие между ними отношения.

                    КАРТА КОНТЕКСТОВ «БОТИНКА»

     ┌───────────┐  партнёрство   ┌───────────┐
     │  Подбор   │◄══════════════►│  Заказы   │
     │  размера  │                │           │
     └─────▲─────┘                └─────┬─────┘
           ║ событием                   │ заказчик
     ┌─────╨─────┐                ┌─────▼─────┐
     │ Возвраты  │                │  Склад    │
     └───────────┘                └───────────┘

     ┌───────────┐                ┌───────────┐
     │  Каталог  │───подстраиваемся──►│ Прайсы  │
     └───────────┘   (чужой формат) └───────────┘

     ┌───────────┐  прослойка     ┌───────────┐
     │  Заказы   │───[перевод]───►│ Старый    │
     └───────────┘                │ склад 1С  │
                                  └───────────┘

     ┌───────────┐                ┌───────────┐
     │ Все части │───очередь─────►│ Платформа │
     └───────────┘                │  входа    │
                                  └───────────┘

  ═══►  обе стороны договариваются
  ───►  одна сторона зависит от другой
  [..]  прослойка-переводчик на границе

проиграйте восемь отношений: что происходит, когда сосед меняет формат

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

каталог восемь отношений между контекстами

Нажмите на карточку, чтобы раскрыть подробности: когда применять, чем платить, как выглядит на практике.

интерактив подберите отношение под ситуацию

Решено 0 из 0.

подробно слой предотвращения порчи (ACL) — как он выглядит в коде

Это самый нужный из восьми паттернов и единственный, который вы будете применять почти в каждой интеграции. Его смысл: чужая модель не должна проникать внутрь вашего контекста. Всё, что приходит снаружи, на границе переводится в ваши понятия; всё, что уходит, — в чужие.

// ─── Плохо: чужая модель растеклась по всему коду ───
// Классы сгенерированы из чужого WSDL и используются напрямую.
class OrderService {
  void ship(ExternalShipmentResponseTypeV2 resp){   // чужое имя в нашем коде
    if("SHP_ST_04".equals(resp.getStatusCode())){  // чужая магия
      order.setStatus("SHIPPED");
    }
  }
}
// Последствия: смена перевозчика = правки по всей кодовой базе;
// значение "SHP_ST_04" знают в шести местах; тесты требуют чужих классов.

// ─── Хорошо: переводчик на границе ───
interface ShippingGateway {                    // НАШ контракт, наши слова
  ShipmentStatus statusOf(OrderId id);           // наш enum, наш тип
}

class DhlShippingAdapter implements ShippingGateway {  // ACL
  public ShipmentStatus statusOf(OrderId id){
    var resp = dhlClient.track(id.value());     // чужое живёт только здесь
    return switch(resp.getStatusCode()){       // перевод один раз, в одном месте
      case "SHP_ST_04", "SHP_ST_05" -> ShipmentStatus.DELIVERED;
      case "SHP_ST_02"            -> ShipmentStatus.IN_TRANSIT;
      default                       -> ShipmentStatus.UNKNOWN;
    };
  }
}
// Смена перевозчика = новая реализация интерфейса. Остальной код не знает,
// что перевозчик вообще менялся. Тесты домена работают на заглушке.

практика как нарисовать карту за один день

зачем это зачем резать систему на части

карта раздела одна история, шестнадцать глав

Главы 1–4 — история трёх попыток. Глава 5 — сам метод по шагам. Главы 6–11 — инструменты, которыми границу находят и проверяют: линзы, языковые границы, матрица изменений, живая модель связности, сценарии. Главы 12–15 — как довести дело до кода и до документа. Опирается на разделы «Домены», «Event Storming», «Ограниченные контексты» и «Карта контекстов». Кнопка переносит к главе.

зачем это зачем у каждого сервиса своя база

зачем это правило почему нельзя ходить в чужую базу

Правило «у каждого сервиса своя база, и чужую трогать нельзя» звучит как бюрократия. На деле это единственное, что держит границу.

попробуйте что можно и что нельзя: нажмите на действие

Два сервиса «Ботинка»: Заказы со своей базой и Склад со своей. Вам нужен остаток товара. Нажимайте на способы — увидите, пройдёт это или нет и почему.

чем заменять пять способов получить чужие данные

Запретили — предложите. Вот все способы, которые остаются, от самого простого к самому мощному. Нажмите на способ.

Устроим проверку. Нажмите на событие — и посмотрите, как поведёт себя каждый из пяти способов. Строку можно нажать, чтобы раскрыть подробности.

принцип база на сервис: что именно запрещено

способы пять способов получить чужие данные

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

интерактив выберите способ под ситуацию

Решено 0 из 0.

частый случай справочники: дублировать или спрашивать

«Страны», «валюты», «категории», «статусы» — данные, которые нужны всем и меняются редко. Отдельный сервис-справочник кажется очевидным решением и почти всегда оказывается неверным.

потери чего вы лишаетесь, разделив базы

Честный список того, что перестаёт работать, и чем это заменяется. Ни одна замена не бесплатна.

отчётность куда девать сквозные отчёты

Вопрос, который топит больше всего переходов на микросервисы: «а как теперь построить отчёт по продажам в разрезе складов и категорий, если данные в четырёх базах?».

задание владение данными

Решено 0 из 0.

зачем это зачем разбираться в согласованности

интерактив CAP вживую: разорвите сеть и выберите

Два дата-центра, у каждого копия баланса. Обычно они синхронны. Порвите сеть между ними — и система обязана выбрать: отказать в обслуживании (сохранив согласованность) или ответить возможно устаревшим (сохранив доступность). Третьего варианта нет, и выбор за вас сделает либо архитектор, либо случай.

теория CAP, и почему её всё время цитируют неверно

PACELC — более полезная формулировка

Если раздел (P), то выбор между A и C; иначе (E, else) — между задержкой (L) и согласованностью (C). Второй половиной пользуются каждый день, а вспоминают о ней редко: даже при исправной сети синхронная репликация на три узла стоит задержки, а чтение с реплики экономит время ценой свежести. Большинство настроек вашей базы — это ручка именно на этой оси.

важнее, чем CAP PACELC: выбор, который вы делаете каждый день

У CAP есть большая беда: она описывает только аварию. Разрыв сети между узлами — событие редкое, пару раз в год. А решение про согласованность вы принимаете не раз в год, а прямо сейчас, в обычный рабочий день.

PACELC достраивает картину. Название — это просто сокращение самой формулы:

  PACELC

  if (P)       если Partition — сеть порвалась
     A or C       выбирай: Availability (отвечать)
                  или     Consistency (отвечать верно)

  Else (E)     иначе — обычная жизнь, сеть цела
     L or C       выбирай: Latency (отвечать быстро)
                  или     Consistency (отвечать верно)

Посмотрите сами

Три копии базы «Ботинка». Клиент покупает последнюю пару 42-го размера. Переключайте состояние сети и выбор — смотрите, что произойдёт.

лестница уровни согласованности: от строгой к никакой

Между «всё сразу везде» и «когда-нибудь сойдётся» есть промежуточные гарантии, и обычно нужна именно одна из них. Нажмите на уровень.

практика что показывать пользователю, пока не сошлось

Отложенная согласованность — это не только техника, но и интерфейс. Четыре рабочих приёма:

задание модель согласованности под задачу

Решено 0 из 0.

зачем это зачем нужны саги

с самого начала что такое сага и зачем она понадобилась

В монолите всё было просто: одно слово @Transactional — и база сама следила, чтобы либо всё записалось, либо ничего. Разделили базы — и это слово перестало работать.

Житейски: вы планируете поездку

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

И вот выясняется, что рейс отменили. Нет никакой общей кнопки «отменить поездку» — вам придётся отдельно звонить в гостиницу, отдельно возвращать страховку. Каждое действие отменяется своим способом, и отмена — это новое действие, а не стирание прошлого.

два способа оркестрация и хореография: проиграйте оба

Сага — это план. А кто этот план держит в голове — вопрос отдельный, и ответов два. Нажимайте «Дальше» и сравнивайте: слева и справа один и тот же заказ.

симулятор сага оформления заказа — уроните любой шаг

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

важно компенсация — это не откат

Что не компенсируется вообще

• Отправленное письмо или пуш. Нельзя «разотправить» — можно только отправить извинение. Поэтому уведомления ставят после точки невозврата, а не до.
• Выданный физический товар. Компенсация превращается в бизнес-процесс возврата с человеком, а не в вызов API.
• Показанные данные. Пользователь уже увидел «заказ оформлен» и сделал на этом основании что-то в реальном мире.
• Внешний эффект у партнёра. Курьер выехал, слот на складе занят, талон в очереди выдан.

классификация три типа шагов саги

Правильный порядок шагов выводится из этой классификации почти механически.

баланс оркестрация против хореографии

не путать оркестратор саги и оркестратор пайплайна

Слово «оркестратор» занято дважды, и на собеседовании этим пользуются. Temporal и Camunda оркеструют саги. Apache Airflow и Dagster оркеструют пайплайны данных. Общего у них только слово.

обязательно четыре вещи, без которых сага сломается

задание саги на практике

Решено 0 из 0.

зачем это зачем нужны outbox и CDC

с самого начала что за проблема и почему её вообще пришлось решать

Житейски: официант и кухня

Официант принял заказ. Ему надо сделать два дела: записать заказ в свой блокнот (чтобы потом выставить счёт) и крикнуть на кухню (чтобы блюдо начали готовить).

Блокнот и кухня — две разные системы. Между двумя действиями всегда есть щель, и если официант в неё провалится (отвлёкся, уволился, упал), одно дело сделано, а второе — нет.

То же самое в коде

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

@Transactional                      // транзакция БАЗЫ
public void placeOrder(Order o) {
    orderRepository.save(o);       // 1. записали в свою базу
                                   //    ← вот здесь щель
    kafka.send("orders", event);   // 2. отправили в брокер
}

Упали между 1 и 2 → заказ есть, склад о нём не знает.
Поменяем местами → событие ушло, а заказа нет.
Третьего порядка не существует.

«А почему нельзя обернуть обе операции одной транзакцией?»

Самый частый вопрос, и ответ простой: транзакция — это функция базы данных. База умеет откатывать свои записи. Отправленное в Kafka сообщение база откатить не может — она о нём вообще не знает.

по шагам как это работает: проиграйте шесть шагов

Тот же заказ, но по правилам outbox. Переключите способ доставки и пройдите шаги — смотрите, что меняется.

симулятор уроните процесс между двумя записями

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

механика transactional outbox — как это устроено

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

-- шаг 1: одна транзакция — бизнес-данные и факт события
BEGIN;
  INSERT INTO orders(id, customer_id, total, status)
       VALUES ('ord-77', 'cus-3', 4200, 'PLACED');

  INSERT INTO outbox(id, aggregate_id, type, payload, created_at)
       VALUES (gen_random_uuid(), 'ord-77', 'OrderPlaced',
               '{"orderId":"ord-77","total":4200,...}', now());
COMMIT;   -- либо и заказ, и событие, либо ничего

-- шаг 2: отдельный процесс (relay) забирает и публикует
SELECT * FROM outbox WHERE sent_at IS NULL
  ORDER BY created_at LIMIT 100
  FOR UPDATE SKIP LOCKED;   -- чтобы несколько реле не мешали друг другу
-- публикуем в брокер, затем:
UPDATE outbox SET sent_at = now() WHERE id = ...;

вариант CDC: читать журнал базы вместо таблицы

Change Data Capture — чтение журнала транзакций СУБД (WAL в PostgreSQL, binlog в MySQL) и превращение изменений в события. Инструмент по умолчанию — Debezium.

обратная сторона inbox: как получателю не обработать дважды

Outbox решает задачу отправителя. У получателя своя: сообщение придёт повторно, и обработать его второй раз нельзя.

BEGIN;
  -- уникальный индекс по message_id: второй INSERT упадёт
  INSERT INTO processed_messages(message_id, consumer, processed_at)
       VALUES ('msg-91', 'inventory', now())
  ON CONFLICT (message_id, consumer) DO NOTHING;
  -- если вставки не было — сообщение уже обработано, выходим

  UPDATE stock SET reserved = reserved + 1 WHERE sku = 'SKU-5';
COMMIT;

задание надёжная публикация событий

Решено 0 из 0.

карта раздела куда мы идём

глава 1 · определение что такое CQRS за одну минуту

Сначала одно слово, без которого дальше не понять ничего. Модель — это форма, в которой код держит данные: класс с полями и методами. Например, класс Order с полями «номер», «товары», «сумма», «статус» и методом «оформить».

Звучит абстрактно, поэтому сразу посмотрим на живом примере. Анна делает в магазине две вещи. Выберите, как написан код, и нажмите на действие Анны. Сравните цифры внизу.

глава 2 · две половины команда или запрос

В первой главе мы разделили код Анны на две половины. У них есть имена, и от них CQRS получил свои буквы: Command — команда, Query — запрос.

Всё, что пользователь делает в системе, бывает двух видов. Отличить их можно одним вопросом: изменится ли что-нибудь после этого действия?

Разложите действия по корзинам. Решено 0 из 0.

глава 3 · почему почему одной модели мало

Сначала расшифруем страшные буквы

  C Q R S

  Command   Query   Responsibility   Segregation
  команды   запросы    ответственность   разделение

  дословно: «разделяем ответственность
            за команды и за запросы»

  по-человечески: ЗАПИСЬ И ЧТЕНИЕ — РАЗНЫЕ ЗАДАЧИ,
                  и делать их одним и тем же кодом
                  не обязательно

Житейски: пекарня

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

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

Теперь — та самая боль. Один заказ, два взгляда

Нажмите на кнопки: что нужно коду, когда он записывает заказ, и что нужно, когда он показывает заказ.

глава 4 · почувствуйте пекарня: одно окно или два

Мы уже знаем определение и видели код. Теперь почувствуем, почему чтение и запись мешают друг другу, когда живут в одном месте. Уйдём от кода в жизнь.

В пекарне работает повар: он принимает заказы и следит за правилами (нельзя продать то, чего нет). Покупатели делают две вещи: спрашивают «что у вас есть?» и покупают. Спрашивают примерно в десять раз чаще, чем покупают.

Выберите, как устроена пекарня, и запустите утренний наплыв. Потом переключите режим и запустите ещё раз, чтобы сравнить.

промежуточный итог что мы уже поняли

Остановимся и соберём всё, что узнали в главах 1–4, в одну карточку. Дальше пойдём внутрь системы.

глава 5 · изнутри путь команды и путь запроса по системе

Теперь проследим по шагам, через что проходит действие Анны внутри сервиса. Выберите сценарий и нажимайте «Дальше». Подсвеченный блок на схеме — то место, где сейчас находится запрос. Ниже видно, что там происходит, какой там код, что лежит в базе и почему сделано именно так.

База одна на оба пути. Это важно: CQRS первого уровня разделяет код, а не хранилища.

глава 6 · как ломается проследите, как одна модель превращается в проблему

Никто не проектирует плохо специально. Разберём, как это получается само — шаг за шагом, на живом примере.

глава 7 · уровни три уровня CQRS — выбирайте минимальный

глава 8 · соберите сами пропустите заказ через уровень 1, 2 и 3

Три уровня легко перечислить, но разницу надо увидеть. Выберите уровень и нажмите кнопку: Анна оформит заказ и сразу же откроет «Мои заказы». Следите, какие блоки загораются, сколько это стоит по времени и увидит ли Анна свой заказ.

глава 9 · выбор какой уровень нужен в каждой ситуации

Правило простое: берите самый низкий уровень, который решает проблему. Каждый следующий добавляет движущиеся части и отставание. Разложите ситуации по уровням. Решено 0 из 0.

глава 10 · отставание модель чтения отстаёт — что видит пользователь

Менеджер меняет цену товара. Запись идёт в основную модель, витрина обновляется событием с задержкой. Покрутите задержку и посмотрите, что увидит покупатель и что увидит сам менеджер.

глава 11 · баланс CQRS честно

глава 12 · а это другое event sourcing: зачем хранить историю вместо остатка

Житейски: банковская выписка

Представьте, что банк хранил бы только остаток на счету: 12 400 ₽. И всё. Никакой истории.

Вы приходите и говорите: «у меня пропали три тысячи». Что ответит банк? Ничего. У него нет данных, откуда взялось число 12 400. Он не может ни доказать свою правоту, ни найти ошибку, ни отменить одну операцию.

Что это даёт — по шагам

глава 12 · продолжение хранить не состояние, а историю

Обычная система хранит текущее состояние: «баланс 1200». Event sourcing хранит все события: «начислено 1000», «начислено 500», «списано 300» — а состояние вычисляется их проигрыванием. Журнал событий неизменяем: исправление — это новое компенсирующее событие, а не UPDATE.

accounts
┌────────┬─────────┐
│ id     │ balance │
├────────┼─────────┤
│ acc-1  │   1200  │   ← как пришли к 1200,
└────────┴─────────┘      неизвестно

events (append-only)
┌───┬────────┬──────────────┬──────┐
│ # │ acc    │ type         │ amt  │
├───┼────────┼──────────────┼──────┤
│ 1 │ acc-1  │ Deposited    │ 1000 │
│ 2 │ acc-1  │ Deposited    │  500 │
│ 3 │ acc-1  │ Withdrawn    │  300 │
└───┴────────┴──────────────┴──────┘
balance = 1000 + 500 − 300 = 1200
плюс ответ на вопрос «почему»

Что обязательно прилагается

• Снимки (snapshots). Проигрывать 400 тысяч событий на каждое чтение нельзя — периодически сохраняется состояние на момент N, дальше проигрывается хвост.
• Проекции. Запросы «покажи всех клиентов с балансом больше 1000» по журналу событий невозможны — нужны построенные из него модели чтения. Поэтому ES почти всегда идёт в паре с CQRS.
• Версионирование событий. События живут вечно, а формат меняется. Нужен план: апгрейд при чтении, версии типов, никогда не менять старые записи.
• Ответ про персональные данные. Журнал неизменяем, а закон требует удалять. Обычное решение — крипто-стирание: персональные данные в событии зашифрованы, удаляется ключ.

глава 13 · задание CQRS и event sourcing

Решено 0 из 0.

зачем это зачем архитектору и аналитику разбираться в сети

карта раздела один Enter, четырнадцать глав

Читайте по порядку: каждая глава разбирает один отрезок пути запроса Анны. Главы 2, 5, 6, 8 и 12 — самые «живые»: там можно крутить настройки и ломать. Кнопка переносит к главе.