Skip to content

Request

Request is the HTTP validation and authorization type for a Service module.

Generated facts

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

Canonical example

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

<?php

namespace {{namespace}};

use Illuminate\Foundation\Http\FormRequest;

/**
 * {{name}} Request
 *
 * Handles validation for {{module}} module in the {{service}} service.
 */
class {{name}} extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize(): bool
    {
        return false;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules(): array
    {
        return [
            //
        ];
    }

    /**
     * Get the error messages for the defined validation rules.
     *
     * @return array
     */
    public function messages(): array
    {
        return [];
    }
}

Responsibility

Request 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

Request 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

  1. ❌ Prohibited: move this responsibility into a neighboring type merely because it is nearby.
  2. ✅ Correct: keep the generated placement and depend only on the documented layer direction.
  3. ✅ 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 place business invariants in a Request.

✅ Correct: Use the Request for adapter validation and keep business rules in Domain workflows.