Перейти к основному содержимому

Initial Event Taxonomy — Первичная таксономия событий платформы

Версия: 1.0
Дата: 24.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует первую рабочую таксономию событий для vitiana-api-platform.

Его задача — не создать финальный AsyncAPI-каталог на все времена, а определить:

  • какие event families уже сейчас необходимы платформе;
  • какие события являются domain-significant;
  • какие события относятся к work queues, а какие к fan-out event streams;
  • какие события должны быть версионируемыми и replay-aware;
  • где событие является просто уведомлением, а где несёт бизнес-критический operational meaning.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

После фиксации eventing baseline уже недостаточно говорить только “нужны очереди, replay и idempotency”.

Платформе нужен первый управляемый словарь событий, чтобы:

  • синхронизировать команды и контуры;
  • не плодить случайные event names;
  • не смешивать queue jobs и domain events;
  • понимать, какие сообщения replay-sensitive;
  • готовить implementation-ready contract package.

Главный Принцип​

Платформа должна различать:

  1. domain events;
  2. operational events;
  3. queue commands / jobs;
  4. escalation / review triggers;
  5. telemetry-adjacent events.

Если эти категории не различать, eventing быстро превращается в хаотичный transport layer без ясного смысла.

Основные Категории Событий​

1. Supplier Intake Events​

Отражают приём supplier reality и продвижение её по ingestion pipeline.

Примеры:

  • supplier.intake.received
  • supplier.intake.rejected
  • supplier.payload.persisted
  • supplier.intake.run.completed
  • supplier.intake.run.failed

2. Normalization And Mapping Events​

Отражают внутренний переход от raw trace к normalized and governed state.

Примеры:

  • supplier.normalization.completed
  • supplier.normalization.failed
  • mapping.candidate.created
  • mapping.review.required
  • mapping.decision.applied

3. Canonical Model Change Events​

Отражают уже не transport progress, а meaningful change in canonical truth.

Примеры:

  • canonical.property.created
  • canonical.property.updated
  • canonical.product.updated
  • canonical.mapping.changed

4. Offer And Publication Events​

Отражают изменение operational offer state and publication admissibility.

Примеры:

  • offer.materialized
  • offer.updated
  • offer.integrity.blocked
  • offer.publication.allowed
  • offer.publication.suppressed

5. Quote And Commercial Events​

Отражают commercial fixation и дальнейшие последствия.

Примеры:

  • quote.created
  • quote.expired
  • quote.invalidated
  • quote.repricing.required
  • quote.repriced
  • commercial.policy.changed

6. Booking Events​

Отражают critical transactional transitions.

Примеры:

  • booking.intent.created
  • booking.confirmation.pending
  • booking.confirmed
  • booking.partially.failed
  • booking.unknown.external.state
  • booking.cancel.requested
  • booking.cancelled

7. Post-Booking Lifecycle Events​

Отражают case-driven post-sale reality.

Примеры:

  • postbooking.change.requested
  • postbooking.amendment.pending
  • postbooking.amendment.applied
  • postbooking.disruption.detected
  • postbooking.support.case.opened
  • postbooking.support.case.resolved

8. Settlement And Clearing Events​

Отражают financial and distribution-side state changes.

Примеры:

  • settlement.event.posted
  • settlement.adjustment.required
  • reconciliation.case.opened
  • reconciliation.case.resolved
  • clearing.hold.created
  • clearing.hold.released
  • clearing.balance.blocked
  • clearing.limit.exceeded

9. Tenant And Usage Governance Events​

Отражают tenant-specific and API-consumption consequences.

Примеры:

  • tenant.enabled
  • tenant.policy.changed
  • tenant.surface.restricted
  • usage.quota.nearing_limit
  • usage.quota.exhausted
  • usage.abuse.detected
  • usage.profile.degraded

10. Governance And Review Events​

Отражают manual-control and review domain.

Примеры:

  • review.case.created
  • review.case.assigned
  • review.case.escalated
  • review.case.closed
  • anomaly.detected
  • anomaly.suppression.applied

Event Families Vs Queue Jobs​

Платформе нужно жёстко различать:

Domain Event​

Сообщает, что platform reality уже meaningfully changed.

Пример:

  • booking.confirmed

Queue Job / Command​

Сообщает, что нужно сделать работу.

Пример:

  • job.booking.confirmation.poll
  • job.quote.expiry.check
  • job.reconciliation.recompute

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

Minimal Required Metadata​

Для domain-significant events минимально должны существовать:

  • event_name
  • event_version
  • event_id
  • occurred_at
  • producer
  • correlation_id
  • causation_id, where applicable
  • tenant_id, where applicable
  • domain object identifiers relevant to the event

Replay-Sensitive Families​

Наиболее replay-sensitive event families:

  • supplier intake and normalization;
  • canonical model changes;
  • quote invalidation / repricing;
  • booking transitions;
  • settlement and clearing changes;
  • governance suppression events.

Для них change management особенно строгий.

Naming Discipline​

На текущем этапе разумно придерживаться схемы:

<domain>.<entity_or_process>.<state_or_action>

Примеры:

  • offer.publication.suppressed
  • booking.confirmation.pending
  • usage.quota.exhausted
  • review.case.escalated

Что Пока Не Нужно Делать​

Пока не нужно:

  • фиксировать исчерпывающий payload schema для всех событий;
  • преждевременно нормализовывать события под один vendor-specific broker format;
  • считать, что каждая state change обязана иметь публичный внешний event;
  • путать telemetry event and domain event.

Что Должно Быть Сделано Дальше​

После фиксации этой первичной таксономии нужно:

  • определить initial payload envelopes;
  • выделить queue jobs отдельно от domain events в implementation docs;
  • зафиксировать versioning rules for event contracts;
  • начать собирать implementation-ready async contract package по приоритетным event families.

Уточнение под Фазы 4–6 (28.04.2026) — каноничные события новых доменов​

Документ опубликован 24.04.2026 в Фазе 3 как первичная таксономия событий. После Фаз 4–6 опубликованы каноничные домены, добавляющие значительные классы событий. Эта секция фиксирует расширение таксономии и направляет к источникам истины каждого класса.

Каноничные новые классы событий по доменам​

Booking state transitions (Фаза 5)​

Каноничные имена — в reference/booking-state-machine.md (14 состояний):

booking.created
booking.submitted
booking.revalidation_started
booking.supplier_confirmation_started
booking.supplier_confirmed
booking.platform_confirmed
booking.partially_confirmed
booking.unknown_external_state    ← критическое 8-е состояние, target SLI менее 1%
booking.failed
booking.cancel_requested
booking.cancel_in_progress
booking.cancelled
booking.amendment_in_progress
booking.completed

Все — domain events с at-least-once + ordered per entity guarantee.

Payment events (Фаза 4)​

Каноничные имена — в reference/payment-domain.md:

payment.intent.created
payment.intent.method_attached
payment.intent.authorized
payment.intent.captured
payment.intent.succeeded
payment.intent.canceled
payment.intent.failed
payment.refund.requested
payment.refund.completed
payment.chargeback.received
payment.chargeback.dispute_submitted
payment.chargeback.won
payment.chargeback.lost
payment.settlement.calculated
payment.settlement.executed
payment.payout.batch_created
payment.payout.batch_completed

Tour Builder saga events (Фаза 5)​

Каноничные имена — в reference/tour-builder-operational-model.md:

tour.composition.created
tour.composition.rule_violation_detected
tour.booking_transaction.started
tour.booking_transaction.compensation_triggered
tour.drift.detected
tour.drift.resolved
tour.proposal.published
tour.proposal.shared
tour.proposal.viewed
tour.proposal.accepted_for_conversion

Гибрид domain + analytical class.

Notification events (Фаза 4)​

Каноничные имена — в reference/notification-and-communication.md:

notification.template.created
notification.event.dispatched
notification.channel.delivery_attempted
notification.channel.delivery_succeeded
notification.channel.delivery_failed
notification.consent.granted
notification.consent.revoked
webhook.subscription.created
webhook.delivery.attempted
webhook.delivery.completed
webhook.delivery.failed
webhook.delivery.retry_scheduled

Search & ranking events (Фаза 4)​

Каноничные имена — в reference/search-and-discovery.md:

search.executed
search.facet_applied
search.result_clicked
search.projection_rebuilt
ranking.policy.applied
ranking.policy.updated

Большинство — analytical events.

A/B testing events (Фаза 4)​

Каноничные имена — в reference/ab-testing-platform.md:

experiment.created
experiment.published
experiment.ramped_up
experiment.completed
experiment.assigned
experiment.exposure
feature_flag.evaluated

Tenancy / isolation events (Фаза 5)​

Каноничные имена — в reference/multi-tenant-isolation-strength.md:

isolation.check.started
isolation.check.completed
isolation.check.breach_detected
isolation.tenant.upgraded
isolation.tenant.downgraded
cross_tenant.access.requested
cross_tenant.access.granted
cross_tenant.access.denied

Security / audit events (Фаза 10)​

Каноничные имена — в reference/security-architecture.md. Это отдельный класс (audit / security events) с immutable WORM storage.

auth.login.success / failed
auth.mfa.required / success / failed
auth.token.issued / revoked
auth.session.expired
authz.action.executed / denied
authz.privilege.escalated
authz.role.granted / revoked
data.sensitive.accessed
data.exported
data.cross_tenant.attempted
admin.user.created / deleted
admin.role.modified
admin.config.changed
admin.secret.rotated / revoked
security.suspicious_activity.detected
security.brute_force.detected
security.injection.attempted
security.data_breach.detected

Operational events — DR / capacity / incidents / SLA (Фаза 6)​

Каноничные имена — в operations/disaster-recovery-and-capacity.md, operations/sla-and-on-call-model.md, operations/runbooks-incident-playbooks.md.

DR events:

dr.recovery.declared
dr.recovery.point_selected
dr.recovery.restored_to_staging
dr.recovery.smoke_tests_passed
dr.recovery.promoted_to_production
dr.recovery.completed
dr.backup.created / verified / expired
dr.drill.scheduled / started / completed_successful / completed_with_issues / failed

Capacity events:

capacity.forecast.created / updated
capacity.threshold.warning_triggered
capacity.threshold.critical_triggered
capacity.provisioning.requested / completed
capacity.degradation.activated / deactivated

Incident events:

incident.detected
incident.runbook.started
incident.runbook.step_completed
incident.escalated
incident.resolved
incident.postmortem.scheduled / completed
incident.action_item.created / resolved

SLA events:

sla.measurement.recorded
sla.breach.detected
sla.breach.acknowledged
sla.service_credit.issued
sla.service_credit.applied

Compliance events (Фаза 4)​

Каноничные имена — в reference/compliance-and-legal.md:

compliance.privacy_review.started / completed
compliance.dsr.received / responded
compliance.breach.detected / notified
compliance.consent.collected / withdrawn
compliance.retention.cleanup_executed
compliance.dpa.signed
compliance.audit.started / completed

Documentation events (Фаза 8)​

Каноничные имена — в development/documentation-governance.md:

doc.created
doc.published
doc.updated.major / minor
doc.archived
doc.review.requested / completed
doc.lint.broken_link_detected
doc.lint.mdx_violation_detected

Каноничный итог уточнения​

Этот документ остаётся первичной таксономией концептуальных классов событий. Каноничные имена событий теперь живут в специализированных документах per домен (см. список выше).

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

Эволюция таксономии — через development/version-evolution-policy-for-async-event-contracts.md.

Уточнение выполнено через no-destruction.