-
Notifications
You must be signed in to change notification settings - Fork 16
Architecture Decisions
These records capture design choices that should remain stable unless a future major version changes the project boundary.
Status: Accepted
LiteBus keeps ICommand, IQuery, and IEvent as separate concepts. A command expresses an intention to change state, a query reads state, and an event reports a fact. Collapsing them into a single request abstraction would remove the semantic API that distinguishes LiteBus from generic mediator libraries.
Status: Accepted
Events can be plain CLR objects. This lets domain projects define events without referencing LiteBus. Applications that prefer explicit markers can still implement IEvent.
Status: Accepted
LiteBus mediates work inside a process. Inbox and outbox packages can store work and facts, but LiteBus does not become a distributed message broker. Broker adapters should live in optional packages.
Status: Accepted
The command inbox stores ICommand for later execution. It does not return handler results and does not replace an outbox. Inbox submission uses ICommandScheduler.ScheduleAsync; ICommandMediator.SendAsync always executes in process.
Status: Accepted
Event mediation dispatches handlers in process. An outbox records facts that must be published after a state change. IEventPublisher.PublishAsync notifies in-process handlers now; IIntegrationOutbox.AddAsync stores an integration event for later publication.
Status: Accepted
The execution context uses ambient async flow so pre-handlers, handlers, post-handlers, and error handlers can share cancellation, tags, and Items without adding parameters to every handler interface. Streaming queries must preserve that context during enumeration.
Status: Accepted
The runtime owns a small dependency registration abstraction. Microsoft DI and Autofac integrations translate LiteBus descriptors into container registrations. The core mediator stays independent of one container.
Status: Accepted
Inbox and outbox storage use stable contract names and integer versions. They do not store assembly-qualified type names as the persisted contract. The contract registry maps CLR types to persisted contracts at the application boundary.