Архитектура B2B-платформы заказов и биллинга

Проведи лёгкую сессию event storming (даже соло, на бумаге или в инструменте для доски) для обнаружения доменных событий B2B-платформы заказов и биллинга. Сгруппируй события в не менее четырёх ограниченных контекстов. Для каждого контекста напиши однопараграфный глоссарий единого языка, определяющий ключевые термины так, как они используются внутри этого контекста — обрати внимание на одинаковые слова, означающие разные вещи в разных контекстах (например, «Order» в Ordering vs. Billing). Нарисуй карту контекстов, показывающую отношения upstream/downstream, и пометь каждую границу паттерном интеграции.

Для каждого ограниченного контекста оцени три кандидатуры структурных стилей — слоёный N-tier, гексагональный (ports and adapters) и чистый/луковый — и выбери тот, который подходит для сложности контекста и волатильности его зависимостей. Простой CRUD-ориентированный контекст может быть лучше обслужен слоёным подходом; основной доменный контекст со сложными бизнес-правилами и множеством инфраструктурных адаптеров (база данных, брокер сообщений, внешние API) выиграет больше всего от гексагональной или чистой архитектуры. Напиши таблицу по каждому контексту с колонками: Context, Style Chosen, Rationale (2–3 предложения), Trade-offs Accepted.

Для каждого ограниченного контекста реши, оправдан ли CQRS (разделение моделей команд и запросов), подходит ли event sourcing (события как система учёта) и должны ли межконтекстные рабочие процессы быть реализованы как event-driven саги. Применяй каждый паттерн только там, где он оправдывает свою сложность. Для контекста Billing явно оцени event sourcing с учётом требований к аудиту и воспроизведению. Для долго выполняющегося рабочего процесса, охватывающего Ordering → Pricing → Billing → Notifications, спроектируй сагу: назови каждый шаг, определи шаг компенсации для каждого режима отказа и реши между хореографией (каждый контекст реагирует на события от предыдущего) и оркестрацией (центральный координатор саги управляет потоком).

Прими конкретное решение о деплойменте: запустить платформу как модульный монолит (все ограниченные контексты в одном деплойменте с сильными модульными границами, обеспечиваемыми системой сборки) или разделить на независимые сервисы с первого дня. Явно примени чеклист распределённого монолита: общая база данных через границы контекстов? синхронная runtime-связанность между контекстами? совместные пайплайны деплоя? Если хоть что-то из этого присутствует, а ты всё равно называешь это микросервисами — у тебя распределённый монолит. Запиши решение как структурированный аргумент: вариант A (модульный монолит), вариант B (сервисы), решение и конкретные условия, при которых ты перешёл бы от A к B или признал бы B ошибкой.

Напиши не менее трёх Architecture Decision Records в стандартном формате (Title / Status / Context / Decision / Consequences) для трёх наиболее значимых решений в твоей архитектуре — примеры: использовать ли event sourcing для Billing, где разместить anti-corruption layer между платформой и внешней ERP, начинать ли как модульный монолит. Для наиболее критичного атрибута качества платформы (выбери один: аудируемость, доступность или p99 задержка потока размещения заказа) определи фитнес-функцию: конкретный тест или метрику, которую можно запускать автоматически или полуавтоматически и чей сбой указывает на то, что архитектура отклонилась от желаемого уровня качества. Чётко сформулируй порог (например, 'каждое событие биллинга должно быть воспроизводимо в пределах 1 секунды от его оригинальной метки времени'; 'ни один модуль в контексте Ordering не должен импортировать из внутренних пакетов модуля Billing').