Roadmap

Roadmap

LiteBus stays an in-process mediator for application-layer work. The command, query, and event APIs remain separate because they model different CQS concepts: a command changes state, a query reads state, and an event reports a fact.

v5 Reliability Baseline

The v5 line focuses on failure behavior that can be tested and explained.

• ICommandMediator.SendAsync always executes immediately in process.
• ICommandScheduler.ScheduleAsync stores ICommand for later execution and returns CommandReceipt<TCommand>.
• IOutboxWriter.AddAsync stores events for later publication and returns OutboxReceipt<TEvent>.
• IIntegrationOutbox.AddAsync restricts durable external publication to IIntegrationEvent.
• Durable inbox and outbox stores use stable message contracts instead of assembly-qualified type names.
• Event routing predicates apply to both PublishAsync(IEvent, settings) and PublishAsync<TEvent>(TEvent, settings).
• Descriptor resolution failures throw MessageDescriptorNotFoundException with the message type, resolve strategy type, on-the-spot registration flag, and registered descriptor count.
• The message registry skips only System and System.* namespaces.
• Unsupported open generic handler shapes throw UnsupportedOpenGenericHandlerException instead of being ignored.

Domain Events and Unit of Work

LiteBus can publish POCO events, so domain models do not need a LiteBus dependency. The recommended pattern is documented in Domain Events and Unit of Work: aggregates collect domain events, the application layer drains them near the transaction boundary, and an outbox stores cross-process notifications in the same database transaction as the state change.

Command handlers own state changes. Query handlers should not send commands, publish events, or write through repositories. Event handlers should be idempotent when retries or durability are part of the application.

Durable Packages

The inbox covers deferred command execution. The outbox covers reliable event publication after a state change.

Implemented package names:

• LiteBus.Inbox.Abstractions
• LiteBus.Inbox
• LiteBus.Inbox.PostgreSql
• LiteBus.Outbox.Abstractions
• LiteBus.Outbox
• LiteBus.Outbox.PostgreSql

Planned package names:

• LiteBus.Inbox.EntityFrameworkCore
• LiteBus.Outbox.EntityFrameworkCore
• LiteBus.Outbox.SqlServer

Transport adapters such as Kafka, RabbitMQ, Azure Service Bus, or MassTransit should stay outside the core package set.

Inbox Processing Contract

Reference inbox implementations should define storage records with these fields:

• command id
• command type name
• serialized payload
• schema version
• created timestamp
• visible-after timestamp
• attempt count
• last error
• processing lease owner
• processing lease expiration
• status: pending, processing, completed, failed, dead-lettered
• idempotency key
• correlation id
• causation id
• tenant id, when the application is multi-tenant

Retry policy support should include bounded retries, backoff, poison message handling, manual replay, permanent failure classification, transient failure classification, and structured failure records.

Idempotency

At-least-once processing requires duplicate-safe handlers. A future idempotency package should include:

• IIdempotentCommand
• ICommandIdempotencyStore
• an open generic command pre-handler for duplicate detection
• optional result caching for immediate result commands
• duplicate keys based on command type and idempotency key

The inbox should use idempotency for state-changing commands. Event handlers that update projections or call external systems should use a similar local key.

Developer Packages

Future developer packages should stay optional:

• LiteBus.Analyzers for duplicate command handlers, query purity checks, inbox misuse, priority conflicts, and unsupported open generic handler shapes.
• LiteBus.Testing as a published package with fake mediators, in-memory inbox and outbox stores, handler invocation recording, and assertion helpers.
• LiteBus.OpenTelemetry with ActivitySource, duration metrics, handler tags, exception recording, and correlation or causation propagation through Items.
• LiteBus.Validation.FluentValidation, LiteBus.Authorization, LiteBus.Caching, LiteBus.EntityFrameworkCore, LiteBus.Outbox.EntityFrameworkCore, and LiteBus.Inbox.EntityFrameworkCore for common application concerns.

Compatibility

Reflection-based registration remains the default developer path. AOT and trimming work should be opt-in and linker-friendly. Source generation is intentionally excluded from this v5 pass.