Learn UseCase Forge

UseCase Forge coordinates application work that has a lifecycle: it can be admitted or rejected, queued, started, cancelled, failed, completed, observed, and eventually closed. This guide starts with the smallest useful UseCase and then adds policies only when a concrete operational problem requires them.

Start with the problem

Consider catalog search. A user can type faster than the network responds, leave the screen while a request is running, or submit a query that makes the old result obsolete. A plain async function can fetch data, but it does not define which request may start, which request should be cancelled, what the UI observes while work is running, or how the feature shuts down.

UseCase Forge makes those decisions explicit:

user or system input
        ↓ Command
input policy decides whether and when it may enter
        ↓ accepted Execution
processing policy relates it to running work
        ↓ handler publishes State
Snapshot exposes State, phase, result, and active work

The package is useful when an operation needs repeatable lifecycle rules. A direct method call remains the better choice for work that has no meaningful admission, concurrency, cancellation, observation, or diagnostics requirements.

The five terms to know first

Recommended path

1. Getting started — install the core package and execute one typed command.
2. Core concepts — understand command, execution, snapshot, result, and group identity.
3. Lifecycle — follow an accepted command from admission to finalization.
4. Policies — choose input and processing behavior deliberately.
5. Architecture — understand the responsibility boundaries behind the public API.

What this documentation does not assume

UseCase Forge is not a dependency injection container, a repository abstraction, or a replacement for domain modeling. It owns execution coordination. Your application continues to own business rules, persistence, navigation, presentation, and service boundaries.