Event Diagrams¶
Executive Summary¶
Event Diagrams provides Mermaid diagrams for the Algosure event-driven architecture. These diagrams cover the Event Mesh, publishing, consumption, reliability, AIOS orchestration, notification triggers, analytics projections, and cross-domain process coordination.
Why This Exists¶
The event architecture spans Domains, Spring Modulith internal events, outbox delivery, AIOS, notifications, analytics, integrations, and audit. Diagrams make the relationships reviewable without defining final infrastructure.
Owner¶
The owner is the Chief Product Officer and Enterprise Architect.
Business Value¶
The diagrams give architecture, engineering, AI, security, data, and integration teams a shared visual baseline for event-driven design.
Event Mesh Diagram¶
flowchart TB
Domain[Source Domain Events]
App[Application Events]
Integration[Integration Events]
Modulith[Spring Modulith Internal Events]
Outbox[Outbox Boundary]
Mesh[Event Mesh]
Process[Cross-Domain Processes]
AIOS[AIOS Event Orchestration]
Notification[Notification Triggers]
Analytics[Analytics Projections]
Audit[Event Audit Trail]
Domain --> Modulith
App --> Modulith
Integration --> Modulith
Modulith --> Outbox
Outbox --> Mesh
Mesh --> Process
Mesh --> AIOS
Mesh --> Notification
Mesh --> Analytics
Mesh --> Audit
Publishing Diagram¶
sequenceDiagram
participant Source as Source Domain
participant App as Application Service
participant Store as Module-Owned Store
participant Outbox as Outbox
participant Mesh as Event Mesh
App->>Source: Execute business behavior
Source-->>App: Fact happened
App->>Store: Persist source-owned state
App->>Outbox: Record past-tense event with metadata
Outbox->>Mesh: Publish reliably
Consumption Diagram¶
sequenceDiagram
participant Mesh as Event Mesh
participant Consumer as Consumer
participant Idem as Idempotency Check
participant Own as Owned Reaction
participant Audit as Audit Trail
Mesh->>Consumer: Deliver event
Consumer->>Idem: Check event ID and business key
Idem-->>Consumer: Safe to process
Consumer->>Own: Update owned projection or workflow
Consumer->>Audit: Record processing result
Reliability Diagram¶
flowchart LR
Event[Event]
Consumer[Consumer]
Success[Processed]
Retry[Retry]
DeadLetter[Dead-Letter Handling]
Review[Operational Review]
Event --> Consumer
Consumer -->|success| Success
Consumer -->|temporary failure| Retry
Retry --> Consumer
Consumer -->|terminal failure| DeadLetter
DeadLetter --> Review
AIOS Event Orchestration Diagram¶
flowchart LR
Event[Domain or Application Event]
Intelligence[Intelligence Module]
AIOS[AIOS]
Professional[Digital Professional]
Proposal[Recommendation or Draft Produced]
OwningModule[Owning Module Application Service]
Approval[Human Approval When Required]
Event --> Intelligence
Intelligence --> AIOS
AIOS --> Professional
Professional --> AIOS
AIOS --> Proposal
Proposal --> OwningModule
OwningModule --> Approval
Notification and Analytics Diagram¶
flowchart TB
Event[Published Event]
Notification[Notification Module]
Channel[Channel Adapter]
Analytics[Analytics Module]
Projection[Analytics Projection]
Dashboard[Dashboard or Report]
Event --> Notification
Notification --> Channel
Event --> Analytics
Analytics --> Projection
Projection --> Dashboard
Cross-Domain Process Diagram¶
flowchart LR
Opportunity[OpportunityMatched]
Bid[BidWorkspaceCreated]
Compliance[ComplianceRiskRaised]
Approval[BidApprovalRequested]
Contract[ContractAwarded]
Opportunity --> Bid
Bid --> Compliance
Compliance --> Approval
Approval --> Contract
Diagram Notes¶
- Events are facts that already happened.
- Event names are past tense.
- Source Domains publish their own events.
- Consumers own their reactions and must not mutate source ownership incorrectly.
- Outbox alignment supports future-safe reliable delivery.
- Event replay is a future capability and requires idempotent consumers, versioning, metadata, and auditability.