Module

Module is a feature slice within one Service and keeps its delivery entrypoints together.

Generated facts

Layer: service
Generated path: app/Pulsar/Services/{Service}/Modules/{Module}
Generator command: None
Workflow method: None
Stability: Current manifest surface (Pulsar 0.4.1)

Canonical example

Generated src/stubs/context.stub — canonical synchronized stub.

app/Pulsar/Services/{Service}/
├── Providers/
│   ├── {Service}ServiceProvider.php
│   └── RouteServiceProvider.php
├── Routes/
│   ├── api.php
│   └── web.php        # generated with make:service --web
└── Modules/{Module}/
    ├── Controllers/    # HTTP handlers (thin)
    ├── Requests/       # Input validation
    ├── Resources/      # HTTP response shaping
    ├── UseCases/       # Workflow orchestration
    ├── Operations/     # Reusable workflow fragments for UseCases
    ├── Jobs/           # Queue entrypoints (thin, idempotent)
    └── Commands/       # CLI/scheduler entrypoints (thin)

Responsibility

Module 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

Module is consumed by the owning Domain or Service workflow and returns a delivery-neutral result. 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.

Boundaries

❌ Prohibited: Do not use a Module as a cross-Service business boundary.

✅ Correct: Keep shared business capability in Domain and let each Service own its delivery slice.

Module ​