Войти
Работаем: пн–пт 9:00–18:00Начать диагностику
Микросервисы не делают систему автоматически современной. Монолит не делает её автоматически устаревшей. Архитектура становится сильной, когда её сложность соответствует реальным требованиям: темпу изменений, нагрузке, размеру команды, независимости доменов, требованиям к отказоустойчивости и стоимости эксплуатации. AMPE использует архитектурный подход не для выбора «модного стека», а для фиксации границ, ответственности и компромиссов, которые система сможет выдерживать годами.
Начать диагностикуОни нужны, когда части системы действительно должны развиваться, масштабироваться или отказывать независимо.
Если команда одна. Деплой общий. Данные тесно связаны. Транзакции постоянно пересекают границы.
Разделение на сервисы может увеличить сложность, не создав независимости.
В таких условиях модульный монолит часто является более сильным архитектурным решением.
Можно разделить код на двадцать сервисов и оставить один логический монолит.
Если каждый сервис знает внутренности соседнего, использует его таблицы и требует синхронного изменения контрактов, распределённость только скрывает связанность.
AMPE сначала ищет границы ответственности и данных, а уже потом выбирает физическую форму развертывания.
При проектировании новой системы.
При серьёзной модернизации legacy.
Когда существующая архитектура замедляет изменения.
Когда отдельные части системы требуют независимого масштабирования.
Когда количество интеграций и зависимостей стало трудно контролировать.
Когда рассматривается переход к event-driven.
Когда необходимо обосновать архитектурные решения не вкусом команды, а требованиями.
Publisher сообщает факт.
Consumers реагируют независимо.
Это сильная модель для событийных процессов.
Но появляются: eventual consistency; повторная доставка; порядок сообщений; schema evolution; наблюдаемость; обработка ошибок.
AMPE использует события там, где преимущества асинхронности оправдывают эту сложность.
Если результат нужен немедленно и зависимость является частью одной операции, обычный request/response может быть самым ясным вариантом.
Архитектура не должна избегать простых механизмов ради идеологии.
Мы выбираем взаимодействие по семантике процесса.
Почему PostgreSQL. Почему Kafka. Почему Kubernetes. Почему отдельный сервис. Почему общая библиотека. Почему eventual consistency.
Если ответ «потому что это стандарт», решение плохо защищено от изменения контекста.
AMPE фиксирует architectural decision records не ради бюрократии, а чтобы сохранять логику выбора и условия, при которых его нужно пересмотреть.
Бизнес-требования определяют функциональные границы.
Нефункциональные требования задают нагрузку, доступность, безопасность и эксплуатацию.
Данные определяют consistency и ownership. Команда — допустимую сложность. Интеграции — характер связей. Roadmap — способность архитектуры изменяться.
Только после этого появляется технологическая форма.
Архитектурные решения становятся объяснимыми.
Сложность появляется там, где она действительно окупается.
Границы ответственности и данных становятся яснее.
Система легче изменяется без каскада неожиданных зависимостей.
Технологический стек следует требованиям, а не наоборот.
И главное — архитектура перестаёт быть коллекцией технологий и становится способом управлять будущей стоимостью изменений.
Первый шаг
Для начала достаточно описать, какие изменения существующая система сегодня делает особенно дорогими, рискованными или медленными. Диагностика покажет, где проблема находится в архитектурной границе, данных, интеграциях или самой модели ответственности.