Event Architecture

Executive Summary

Event Architecture defines the event-driven architecture for Algosure. It describes domain events, application events, integration events, the Event Mesh, Spring Modulith internal events, outbox alignment, reliability, auditability, versioning, and consumer rules.

Why This Exists

Algosure coordinates procurement work across Domains, AIOS, workflows, notifications, analytics, integrations, and future external delivery channels. Events allow modules and processes to react to facts that already happened without violating source-domain ownership.

Owner

The owner is the Chief Product Officer and Enterprise Architect.

Business Value

A governed event architecture reduces hidden coupling, supports cross-domain process coordination, improves auditability, and preserves a future path toward reliable asynchronous delivery and event replay.

Event Architecture View

flowchart TB
    Source[Source Domain Module]
    DomainEvent[Domain Event]
    AppEvent[Application Event]
    Outbox[Outbox Boundary]
    Mesh[Event Mesh]
    Consumer[Consuming Module]
    AIOS[AIOS Event Orchestration]
    Notification[Notification Triggers]
    Analytics[Analytics Projections]
    Integration[Integration Events]
    Audit[Event Audit Trail]

    Source --> DomainEvent
    Source --> AppEvent
    DomainEvent --> Outbox
    AppEvent --> Outbox
    Outbox --> Mesh
    Mesh --> Consumer
    Mesh --> AIOS
    Mesh --> Notification
    Mesh --> Analytics
    Mesh --> Integration
    Mesh --> Audit

Event Types

Event Type	Meaning
Domain event	A business fact that happened inside a source Domain and is owned by that Domain.
Application event	A use-case or workflow fact produced by application-service coordination where the fact is not purely aggregate-owned.
Integration event	A fact exchanged at the external boundary, either published to external parties or produced from external observations.
Internal event	A Spring Modulith event used for module-to-module coordination inside the backend.

Core Rules

Rule	Requirement
Events are facts	Events describe something that already happened.
Events are past tense	Event names must use past-tense business language.
Source Domains publish their own events	The module that owns the fact publishes the event.
Consumers do not take ownership	Consumers may react, project, notify, analyze, or orchestrate, but must not mutate source ownership incorrectly.
Events carry metadata	Events must include identifiers for tenant, organization, correlation, causation, version, time, actor, and source where relevant.
Consumers are idempotent	Duplicate delivery must not corrupt state or duplicate business effects.
Outbox is the reliability boundary	Events that need reliable delivery should be captured with the state change that produced them.

Event-Driven Responsibilities

Responsibility	Architecture Owner
Event meaning	Source Domain or owning application service.
Event publication	Source module through internal event and outbox boundaries.
Event routing	Event Mesh.
Event reaction	Consuming module, AIOS, Notification, Analytics, or Integration boundary.
Event metadata standard	Architecture and platform governance.
Event audit trail	Security, audit, and source ownership governance.
Event versioning	Publishing module with architecture review for breaking changes.

Non-Implementation Boundary

This document does not define broker technology, queue names, Spring annotations, event classes, payload schemas, retry intervals, outbox tables, or infrastructure configuration.