Модульный монолит – это архитектурный подход, при котором каждый модуль отвечает за собственные данные и бизнес‑логики, но при этом все модули взаимодействуют через чётко определённые контракты. В видео «Два агента будут общаться между собой: эксперимент с контрактом для медиа» автор подробно рассматривает, как правильно распределять таблицы, управлять владением и синхронизацией данных, а также как AI‑агенты могут помочь в проектировании этих контрактов. Ниже – практическое руководство, ключевые выводы и вопросы для дальнейшего обсуждения.
Context and practical value
Видео описывает архитектурные решения для модульного монолита HackOnVibe, включая владение таблицами, проекции, transactional outbox и эксперимент с AI‑агентами, которые проектируют контракт для Media‑модуля.
В статье будет проанализирована структура видео, выделены ключевые практики и предложены конкретные шаги для внедрения в собственные проекты, а также сформулированы вопросы для дальнейшего обсуждения.
Tutorial profile
- Format: case_study
- Topic: devtools
- Audience: intermediate
- Tools: Claude Desktop
Key takeaways
- Таблица должна принадлежать модулю, который гарантирует её инварианты.
- Проекции – локальные копии данных, которые потребитель хранит самостоятельно.
- Transactional outbox объединяет событие и изменение данных в одной транзакции.
- AI‑агенты могут сравнивать дизайн‑документы и предлагать контракты, но их решения требуют проверки.
- Механизм «машинного сторожа» позволяет постепенно включать контроль границ модулей.
Разделение таблиц по модулям
Автор показывает, как в таблице 51 определить владельца и почему каждая таблица должна принадлежать только одному модулю. Это предотвращает конфликт инвариантов и упрощает миграции.
Проекции и outbox‑транзакции
Обсуждается, как проекции работают как локальные данные потребителя, а outbox‑транзакции обеспечивают атомарность события и изменения данных.
AI‑агенты в проектировании контрактов
Эксперимент с двумя субагентами (Opus 5 и Bubble 5.1) демонстрирует, как агенты могут совместно обсуждать и согласовывать контракт для Media‑модуля, но их выводы требуют проверки по схемам и коду.
Practical next steps
- Определите владельца каждой таблицы и зафиксируйте его в реестре владения.
- Создайте проекции для потребителей, которые не требуют прямого доступа к основной таблице.
- Реализуйте transactional outbox, чтобы событие и изменение данных шли в одну транзакцию.
- Запустите AI‑агентов для генерации и проверки контрактов, но всегда проверяйте их выводы вручную.
Limits and verification
- Видео не содержит конкретных команд или кода, поэтому детали реализации остаются на уровне концепции.
FAQ
Что такое реестр владения?
Это таблица, в которой фиксируется, какой модуль отвечает за конкретную таблицу и какие права доступа к ней имеются.
Как работает transactional outbox?
Outbox хранит событие и изменение данных в одной транзакции, чтобы гарантировать, что оба действия либо выполняются, либо откатываются вместе.