usecase-go

Define a struct with unexported dependency fields, a NewXHandler constructor, and Name() plus Execute(ctx, input) methods implementing types.Handler[I,O]. Register it with fx.Provide(usecases.NewXHandler) in module.go; controllers consume it as a concrete pointer type without fx.As.

Wrap all DB mutations in uow.Execute(ctx, func(txCtx context.Context) error { ... }) and pass txCtx to every repository call. The UnitOfWork commits when the callback returns nil and rolls back on any returned error.

Persist domain events inside the same UnitOfWork transaction as the entity save by looping over entity.PullDomainEvents() and calling domainEventRepo.Save(txCtx, e). Never call a mediator directly; the outbox dispatcher delivers events asynchronously after commit.

No. External I/O such as service calls or HTTP requests must run after uow.Execute returns. Running them inside the closure holds the database connection open during the call and increases the risk of partial state on failure.

Go use cases are also invoked from non-HTTP paths like webhook choreography, integration-event handlers, and sync workers where no controller request struct exists. The validate tags on the Input struct are the only format gate on those paths, so they are required.

Do not use it for read queries serving UI or internal coordination, which follow the query skill's ctx-local read pattern, or for reacting to events, which belongs to the event handler skill. It is meant for state-changing commands needing transactional orchestration.