https://laravel.io/forum/feed The RSS feed for the Laravel.io forum contains a list of all threads posted by community members. 2026-09-26T13:13:41+00:00 https://laravel.io/30923

2026-09-26T13:13:41+00:00 https://laravel.io/30919

2026-09-26T13:13:41+00:00 https://laravel.io/30922

cancel(); ``` The application layer coordinates the use case: ```php $cancelOrder->handle($order, $actor); ``` The Action might handle authorisation, persistence, transactions, and event dispatch; so the controller only needs to deal with HTTP and invoke the use case. ## The other problem: consistency between AI sessions This was the part that made Laravel Boost particularly interesting for this experiment. I didn't just want a document saying: > "Please use DDD." That leaves a huge amount open to interpretation. Instead, the package contains focused skills for specific tasks: ```text creating-action creating-data creating-domain-model creating-value-object creating-domain-service creating-domain-event creating-integration introducing-repository using-laravel-entry-points testing-domain testing-action ``` So when an agent is creating a value object, introducing an integration, testing a domain rule, or implementing an Action, it can receive guidance specifically for that task. ## Architecture rules should also be executable Instructions for an AI agent are useful, but I didn't want the package to rely entirely on instructions and LLM's interpretation. This is why the package also publishes Pest architecture tests. They check things such as dependency boundaries between Domain, Application, Infrastructure and delivery code, as well as a few conventions used by the package. ## Existing applications shouldn't require a rewrite Installing the package does **not** mean: > "Move the whole application into Domain/Application/Infrastructure." Existing code stays where it is. ## Installation The package currently supports Laravel 12 and 13 and requires Laravel Boost. Install it as a development dependency: ```bash composer require --dev maiobarbero/laravel-boost-ddd ``` If the project doesn't already use Pest: ```bash composer require --dev pestphp/pest vendor/bin/pest --init ``` Then: ```bash php artisan boost-ddd:install ``` The installer registers the package with Boost, installs the guidelines and skills for the configured agents, and publishes the architecture test. ## I'd like feedback on the architectural choices This is a `1.0`, so one reason I'm sharing it here is that I'm interested in feedback from people who build larger Laravel applications. In particular, I'm curious about where other Laravel developers draw these boundaries: - When does an Eloquent model become too responsible? - When is a repository actually worth introducing? - Do you prefer use-case Actions, application services, or another pattern? - How much architecture should be enforced automatically versus left to review? - And if you're using coding agents, how are you keeping architectural decisions consistent between sessions? I'm deliberately trying to stay somewhere between **"everything in controllers/models"** and **"every Laravel feature needs six abstractions"**. If that's a problem you're dealing with too, I'd be interested to hear how you're approaching it. Repository: **[https://github.com/maiobarbero/laravel-boost-ddd](https://github.com/maiobarbero/laravel-boost-ddd)**]]>

2026-09-26T13:13:41+00:00 https://laravel.io/30921

2026-09-26T13:13:41+00:00 https://laravel.io/30914

2026-09-26T13:13:41+00:00 https://laravel.io/30920

2026-09-26T13:13:41+00:00 https://laravel.io/30918

2026-09-26T13:13:41+00:00 https://laravel.io/30917

2026-09-26T13:13:41+00:00 https://laravel.io/30916

2026-09-26T13:13:41+00:00 https://laravel.io/30915

2026-09-26T13:13:41+00:00 https://laravel.io/30913

2026-09-26T13:13:41+00:00 https://laravel.io/30912

2026-09-26T13:13:41+00:00 https://laravel.io/30906

2026-09-26T13:13:41+00:00 https://laravel.io/30900

2026-09-26T13:13:41+00:00 https://laravel.io/30881

2026-09-26T13:13:41+00:00 https://laravel.io/30873

2026-09-26T13:13:41+00:00 https://laravel.io/30872

[ 'token' => env('ACME_TOKEN'), ], ]; ``` Application code should then read it through Laravel's configuration repository: ```php $token = config('services.acme.token'); ``` I also test deployment builds with configuration cached. That catches the direct-access problem before production. ## Environment-file drift remains A related issue is keeping the key inventories of `.env`, `.env.testing`, `.env.production`, `.env.sample`, or renamed templates aligned without comparing or exposing their values. Some practical questions for teams maintaining several environments: - Do you treat every `.env.*` file as a complete contract, or are some of them partial Vite-style layers? - How do you detect a key used by application code but declared nowhere? - How do you handle keys consumed only by Docker, CI, a process manager, or hosting infrastructure without producing false positives? - Do commented assignments in non-active templates count as documented optional keys in your workflow? - Do you audit raw `getenv()`, `$_ENV`, `$_SERVER`, Vite, Blade, and PHPUnit usage as part of the same review? ## An optional development guard While working through these cases, I built the open-source [Laravel Env Guard](https://github.com/Codegenie-BE/laravel-env-guard): ```bash composer require --dev codegenie-be/laravel-env-guard ``` It runs during guarded Artisan boots in the local environment by default. It checks unsafe `env()` usage and environment-key drift, but reports keys only: no values, telemetry, network calls, automatic `.env` changes, or production scanning by default. The current release supports Laravel 12 and 13 across their valid PHP 8.2–8.5 combinations. Disclosure: I maintain this package through Codegenie. I am looking for technical feedback about real-world environment-file conventions and false-positive or false-negative cases, not stars. Please do not share real environment values or secrets.]]>

2026-09-26T13:13:41+00:00 https://laravel.io/30871

$user->id, 'processor_token' => $charge->id, // e.g. Stripe charge/payment intent ID 'amount' => $amount, 'status' => 'pending', ]); ``` **2. Enforce Idempotency on Every Write Endpoint** Network retries, double-taps on the frontend, and queue redelivery can all cause the same charge or transfer request to hit your API twice. Require an Idempotency-Key header and store a hash of processed keys so a repeated request returns the original result instead of creating a duplicate transaction. ``` php if (Cache::has("idempotency:{$key}")) { return Cache::get("idempotency:{$key}"); } ``` Laravel doesn't do this for you out of the box, so it's worth building as reusable middleware if you're handling any kind of money movement. **3. Use Database Transactions + Locking for Balance Updates** Never do a read-then-write balance update without locking the row. Race conditions here are exactly how double-spends happen. ``` php DB::transaction(function () use ($walletId, $amount) { $wallet = Wallet::where('id', $walletId)->lockForUpdate()->first(); if ($wallet->balance < $amount) { throw new InsufficientFundsException(); } $wallet->decrement('balance', $amount); }); ``` **4. Rate Limit Aggressively on Financial Endpoints** Laravel's built-in throttle middleware is a good start, but for payment endpoints specifically, consider tighter limits and per-user (not just per-IP) throttling to blunt card-testing and enumeration attacks. ``` php Route::middleware('throttle:10,1')->group(function () { Route::post('/payments/charge', [PaymentController::class, 'charge']); }); ``` **5. Verify Webhooks Cryptographically** If you're consuming webhooks from a payment processor, always verify the signature before trusting the payload. Don't just check that the request "looks right." ``` php $sig = $request->header('Stripe-Signature'); $event = \Stripe\Webhook::constructEvent($payload, $sig, config('services.stripe.webhook_secret')); ``` **6. Log Everything, But Never Log Sensitive Data** Full audit trails matter a lot for financial systems — who initiated a transaction, when, from where. Just make sure your logging channel scrubs card numbers, tokens, and auth headers before anything hits disk. **7. Use Policies/Gates for Every Financial Action** Don't rely on route middleware alone. Wrap every transfer, withdrawal, or balance-changing action in an explicit authorization check via Laravel's Policy classes, so it's obvious and testable that a user can only act on their own wallet/account. None of this is Laravel-specific in principle — it's standard fintech engineering discipline — but Laravel gives you solid primitives (transactions, middleware, policies, queues) to implement it cleanly if you use them deliberately rather than bolting security on after the fact. At Nimble AppGenie we've run into a lot of these issues while working on [fintech APIs](https://www.nimbleappgenie.com/blogs/top-fintech-apis-for-every-startup/) for wallet and payment products, and idempotency + row locking are consistently where teams get bitten first. What are others doing for fraud detection or velocity checks at the API layer? That's the piece I'm still refining.]]>

2026-09-26T13:13:41+00:00 https://laravel.io/30869

2026-09-26T13:13:41+00:00 https://laravel.io/30868

2026-09-26T13:13:41+00:00