---
name: laravel-clean-architecture
description: Implement Domain-Driven Design with typed DTOs, repository interfaces, and single-responsibility Action classes in Laravel. Use when creating domain folders, binding repository contracts in providers, or passing DTOs between layers.
metadata:
  triggers:
    files:
    - 'app/Domains/**/*.php'
    - 'app/Providers/*.php'
    keywords:
    - domain
    - dto
    - repository
    - contract
    - adapter
---
# Laravel Clean Architecture

## **Priority: P1 (HIGH)**

## Workflow: Add Domain Feature

1. **Create domain folder** — `app/Domains/Order/{Actions,DTOs,Contracts}/`.
2. **Define DTO** — Create `readonly class` with typed constructor properties.
3. **Create contract** — Define repository interface in `Contracts/`.
4. **Implement repository** — Build Eloquent implementation; bind in `AppServiceProvider`.
5. **Write Action class** — Single-responsibility use-case logic consuming DTO.
6. **Verify bindings** — Run `php artisan tinker` and resolve interface to confirm DI works.

## Action + DTO Example

See [implementation examples](references/implementation.md#action--dto-example) for Action class with DTO and domain structure patterns.

## Implementation Guidelines

### Domain-Driven Design (DDD)

- **Grouping**: Organize code in **`app/Domains/Order/{Actions,DTOs,Contracts}/`**. Group by business domain (**`User, Order, Payment`**) — not by type (Controllers, Models).
- **Core Models**: Keep standard Eloquent models in **`app/Models/`**.
- **Separation**: **Never put Eloquent queries in controllers**; delegate to **Action classes** for use-case logic.

### Data Transfer Objects (DTOs)

- **Immutability**: Use `readonly class` (PHP 8.2+) or `readonly` properties (PHP 8.1+). DTOs cross boundaries — pass between layers instead of raw arrays or Eloquent models.

### Repository Pattern & Decoupling

- **Interfaces**: Create **`Contracts/OrderRepository interface`** and implement **`EloquentOrderRepository`**.
- **Binding**: Bind interfaces to implementations in **`AppServiceProvider`** via **`$this->app->bind(OrderRepository::class, EloquentOrderRepository::class)`**.
- **Usage**: **Inject interfaces** into your actions/services.
- **Layer Flow**: Controller → Action → Repository Interface → Eloquent. DTOs cross boundaries at every layer transition.

## Anti-Patterns

- **No Eloquent in Controllers**: Bridge layers with DTOs and Actions.
- **No raw arrays across layers**: Use typed `readonly` DTOs.
- **No God Services**: Break into single-responsibility Actions.
- **No concrete dependencies**: Depend on Interfaces, not implementations.

## References

- [DDD & Repository Patterns](references/implementation.md)

## Boundary checklist

- Keep controllers free of Eloquent queries and pass DTOs across the boundary between HTTP and domain layers.
- Inject `OrderRepository` contracts into Actions; bind them in the container instead of creating globals or grouping code only by technical type.
- Prefer immutable transfer data or readonly DTOs to prevent accidental mutation.

## Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
- bind them,Bind the contract,container bindings
- boundary between HTTP,cross-layer API,pass it to
- controllers free of queries,no Eloquent query,Keep controllers free
- inject `OrderRepository`,inject OrderRepository,depends on the Action
- instead of creating global,rather than by technical type
- no Eloquent query,contain no Eloquent,free of queries
- prevents accidental mutation,immutable transfer data,readonly DTO