Architecture

Overview

The architecture follows a clean separation between write-side (commands → sagas → entities) and read-side (events → views → view models), connected through an event queue.

• Aggregates encapsulate business logic and send commands
• Command Bus routes commands to appropriate saga handlers
• Sagas handle commands and maintain consistency
• Sagas persist entities to the Entity Store
• Sagas raise events to the Event Queue
• Event Queue dispatches events to subscribers
• Views project events into read models (ViewModels)
• Command Store persists commands for replay

Core Architectural Patterns

High-Level Component Diagram

Command Processing Path

1. ICommandBus — Entry point for command publishing
2. CommandBus — Manages command persistence (assigns sequence number) and dispatching
3. ICommandDispatcher — Routes commands to subscribers
4. CommandDispatcher — Dispatches to all registered ICommandSubscriber instances
5. CommandSubscriber — Routes commands to appropriate Sagas
6. ISaga — Handles commands, persists entities, and produces events

Event Processing Path

1. IEventQueue — Entry point for event publishing (from Sagas)
2. EventQueue — Manages event distribution
3. IEventDispatcher — Routes events to subscribers
4. EventDispatcher — Dispatches to all registered IEventSubscriber instances
5. Aggregate.EventSubscriber — Routes events to Aggregates implementing ISubscribes<TEvent>
6. Projections.EventSubscriber — Routes events to Views implementing IProjectOn<TEvent>

Storage Abstractions

The adapter pattern provides scoped wrappers around the store interfaces, ensuring proper lifecycle management in DI containers.

Service Lifetimes

// Configure component lifetime (default: Singleton)
services.UseSourceFlow(ServiceLifetime.Singleton, assemblies);

Built-in Telemetry

The framework includes built-in OpenTelemetry support via IDomainTelemetryService:

Tags include command/event type, entity IDs, sequence numbers, and subscriber counts.

Cloud Extension Points

The interface-based design makes cloud extension seamless:

• ICommandDispatcher — New implementation for AWS SQS dispatching
• IEventDispatcher — New implementation for AWS SNS publishing
• Selective routing — Only cloud-configured commands/events go to cloud; others stay local
• Maintained local processing — Existing local processing works alongside cloud dispatch

Design Principles

• Separation of Concerns — Commands, Events, Aggregates, Sagas, and Views are distinct
• Interface-based Design — All major components use interfaces for extensibility
• Dependency Inversion — Components depend on abstractions, not implementations
• Single Responsibility — Each component has a focused purpose
• Open/Closed Principle — Extensible through new implementations without modifying core