FcqrsBuilderType

Register an aggregate. The shard is constructed via DI (ctor args resolved from the container) and Init'd at startup; its Handler and AggregateRefs are registered so endpoints/sagas can resolve them. Hosted services may inject these handles in their constructors and invoke them after FCQRS starts.

DI variant of the filtered single-event handler overload.

DI variant of the single-event handler overload.

Register the read-model projection, building the handler from DI. Use this overload when the projection needs services, e.g. an ILoggerFactory.

Register the read-model projection with a filtered single-event handler: the handler updates the read model and returns Publish/Suppress per event to control whether it wakes subscribers.

Register the read-model projection with a single-event handler: the handler just updates the read model (returns void); each aggregate event is then published to subscribers as-is. Use the list-returning overload when notifications must be filtered, e.g. suppressing intermediate events so read-your-writes only wakes on the final one.

Register the read-model projection. It follows each aggregate's and saga's own sequence numbers, so it never skips a stored event. Without a name it keeps its progress in memory and reads the whole journal at each start, for a read model kept in memory. With a name it stores its progress in the journal database and resumes, and a handler can see an event again after a crash. A handler that throws terminates the process. The handler returns the notifications to publish. Resolve FCQRS.Projections.IProjection to wait for it.

Register a saga. `create` builds it; use sp.AggregateFactory<T>() to reference the aggregates it sends commands to. The saga's StartsOn decides which originator events start an instance. C# infers TData, TState and TEvent from the saga class `create` returns, so a call names no type arguments: .AddSaga(sp => new Transfer(sp.AggregateFactory<Account>()))

Register a transactional projection with journal-wide CatchUpAsync support. The handler must write through the supplied connection and transaction and await all database work. FCQRS commits updates with durable contiguous progress. Resolve FCQRS.Projections.IProjection from DI to wait after an aggregate reply. Ordering is per persistence ID, and unprocessed journal history must be retained.

Enable Akka's internal logging (FCQRS ships it OFF). `level` maps to akka.loglevel; by default akka.stdout-loglevel is set to the same value. FCQRS's own logs are unaffected — they follow the host's ILoggerFactory.

Set the builder-wide default snapshot cadence: every aggregate/saga whose own SnapshotPolicy is Default uses this instead. Per-entity overrides (Every n / NoSnapshots) always win; leaving this unset keeps the config key (config:akka:persistence:snapshot-version-count) / 30 fallback.

Register a deterministic, one-to-one historical event conversion. Chained conversions follow declared envelope payload types. Duplicate source registrations and cycles fail. The host installs these conversions before initializing aggregates, sagas, or projections. Each actor system has its own registry, fixed for its lifetime. Only FCQRS journal reads are converted; stored envelopes, live messages, and application-owned snapshot state are unchanged. Keep old payload types readable and register readers before deploying writers. Finish builder registrations before building or resolving the host; resolving IActor fixes this configuration. Converters may run concurrently and must be thread-safe.

Register stable journal names for payload types: manifests become "fcqrs:ev(doc.event)" instead of CLR type names, so types can be renamed/moved freely (update the mapping; old rows keep reading).

The message-flow narrative — which command reached which aggregate and what it yielded, saga state transitions, the commands sagas issue — is written at Information level to the "FCQRS.MessageFlow" category and is ON by default: these lines describe your application's messages, not FCQRS internals. Turn it off here (a process-wide switch), or filter the category in your logging configuration.

Whether message *payloads* appear in diagnostics detail — the span tags (command.type / event.type) and the message-flow log lines. ON by default. Span *names* are always low-cardinality case names regardless, so this never affects tracing rules or grouping. Turn it off for sensitive domains: tags and log lines then carry the case name only.

The underlying service collection (so you can keep chaining .Add… on it).