-
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. Durable command inbox and future 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. Result commands marked with [StoreInInbox] fail with ResultCommandInboxNotSupportedException.
Status: Accepted
Event mediation dispatches handlers in process. An outbox records facts that must be published after a state change. Keeping those responsibilities separate avoids making every in-process event publish pay for durability.
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.