Laravel Beyond Laravel Package

Getting Started

Requirements: PHP 8.2+ and Laravel 11.x or 12.x. As of v7.1.0, Laravel 10.x is no longer supported — pin the package to ^7.0 if you're still on Laravel 10, or upgrade the framework first.

Install:

composer require regnerisch/beyond

Then run the package installer to publish its config and register the artisan commands:

php artisan beyond:install

Where to look first:

• config/beyond.php — namespaces for Actions, Domains, and Responders, plus any routing defaults. Read this before generating anything; it determines where every scaffolded file lands.
• The beyond:make:* commands (php artisan list beyond) — this is how you actually use the package day-to-day.
• The generated stubs — they're the best documentation of the expected shape of an Action/Domain/Responder.

First use case: model a single endpoint as a full ADR triad. New in v7.1.0, beyond:make:adr-action scaffolds the Action, Domain, and Responder together:

php artisan beyond:make:adr-action CreateUser

Wire it into routes/web.php as a single-action route (Route::post('/users', CreateUser::class)), put the business logic in the Domain, and keep the Responder responsible for the HTTP response. This is the intended "one request, one file triple" workflow and is the fastest way to see the pattern the package is built around.

Implementation Patterns

ADR over MVC for endpoint code. The package's value is that every endpoint is a self-contained Action. Reach for it when controllers start accreting private methods and you want each request to be an invokable, testable class. Keep traditional controllers for CRUD-heavy resource routes where the pattern is overhead.

Scaffold the triad, not the pieces. Prefer beyond:make:adr-action Foo over manually running make:action, make:domain, and make:responder. The combined command (new in v7.1.0) generates matching class names and namespaces, so you don't hit import/typo issues between the three files. Use the individual commands only when an Action genuinely needs a second Domain or Responder variant (e.g. a JSON vs. HTML responder).

Routing. Register Actions directly as route handlers:

Route::post('/users', CreateUser::class)->name('users.store');

This keeps route files declarative and lets you attach middleware per Action.

Dependency injection. Actions are resolved by the container, so constructor-inject services, repositories, and form requests just like a controller. Keep the Action thin: validate (via a FormRequest or a small guard), delegate to the Domain, hand the result to the Responder.

Testing. Because an Action is a plain class, unit-test the Domain in isolation and use $this->post(...) feature tests against the Action endpoint. This split is the main testing win — you get real unit tests for the business logic without mocking the HTTP layer.

Integration with existing apps. You don't have to convert everything. Introduce ADR action-by-action for new or painful endpoints, and leave existing controllers in place. The package is additive, so a gradual adoption path works well.

Gotchas and Tips

Laravel 10 removal is a real breaking change. v7.1.0 drops Laravel 10 support. If you're on 10.x, composer will refuse the upgrade — either stay on the 7.0.x line or plan the framework upgrade. Check composer.json constraints before bumping.

Laravel 12 is now supported. If you deferred upgrading the framework because this package lagged, v7.1.0 unblocks you. Verify other packages in the stack support 12.x before flipping laravel/framework to ^12.0.

beyond:make:adr-action is new — verify output against your config. The combined command reads the namespaces from config/beyond.php. If you've customised namespaces, confirm the generated files land where the rest of your code expects, and that the Action's references to the Domain/Responder resolve. Run php artisan optimize:clear after changing config so cached config doesn't point the command at stale paths.

Watch class-name collisions. If you already created an action with the individual commands and then run beyond:make:adr-action with the same name, you'll get conflicts or be prompted to overwrite. Choose distinct names, or generate the missing pieces individually.

Namespaces are config-driven. Autoloading of generated classes depends on PSR-4 mappings matching config/beyond.php. If a freshly generated Action "class not found", compare the config namespace with your composer.json autoload.psr-4 entries and run composer dump-autoload.

Keep Responders boring. The easiest way to erode the pattern is to put business logic in the Responder. Treat it strictly as output formatting (JSON payload, redirect, view) so Domains stay unit-testable and side-effect free.

Extension point: custom stubs. If your team has house style (strict types, docblocks, base classes), customise the published stubs rather than hand-editing generated files — otherwise every scaffold drifts from convention.