UseCase
UseCase owns one application workflow, including transaction boundaries and domain-event emission.
Generated facts
- Layer
- service
- Generated path
app/Pulsar/Services/{Service}/Modules/{Module}/UseCases/{Name}.php- Generator command
make:use-case- Workflow method
execute()- Stability
- Current manifest surface (Pulsar 0.4.1)
Canonical example
Generated src/stubs/use-case.stub — canonical synchronized stub.
<?php
namespace {{namespace}};
/**
* {{name}} UseCase
*
* Orchestrates {{module}} workflows in the {{service}} service, including Operation calls when shared workflow fragments are needed.
*/
class {{name}}
{
public function execute()
{
//
}
}
Responsibility
UseCase owns the responsibility stated above; it must not absorb delivery, transaction, or unrelated cross-layer behavior.
Placement and dependencies
Keep this type in its generated Service Module path. It may depend inward on Domain capability, but it must not make another Service its behavioral dependency.
Workflow and tests
UseCase is called from a UseCase workflow; only the UseCase owns its transaction and event boundary. Test its direct contract, its rejected boundary cases, and the caller or callee that proves the rule in application flow.
Three pitfalls
- ❌ Prohibited: move this responsibility into a neighboring type merely because it is nearby.
- ✅ Correct: keep the generated placement and depend only on the documented layer direction.
- ✅ Correct: test the boundary through the caller and the return or side effect visible to its callee.
Related reading
Read architecture placement for shared rationale and follow this page’s related concept links for the adjacent responsibility.
Boundaries
❌ Prohibited: Do not call another UseCase from a UseCase.
✅ Correct: Extract reusable multi-step work into an Operation.