app/
├── Http/Controllers/
├── Models/
├── Services/
└── Repositories/Works well for simple CRUD, but business rules can spread across controllers, services, models, jobs and observers.
Open source · Ready for real projects
Domain-first
Laravel systems.
Laravel DDD Toolkit helps teams structure large, modular Laravel applications around explicit business domains, clear use cases, ports and adapters.
Designed for
Laravel
PHP 8.2+
Composer
▾ Billing/
▾ Domain/
▾ Entities/
Invoice.php
▾ Application/
▾ UseCases/IssueInvoice/
IssueInvoiceHandler.php
▾ Ports/Out/
InvoiceRepository.php
▾ Infrastructure/
▾ Persistence/Adapters/
EloquentInvoiceRepository.php
▾ Http/Controllers/
InvoiceController.php
⌘
Generated with
make:module
✓
Hexagonal
ports + adapters
01 · Learn DDD
DDD explained for
DDD explained for
Laravel developers.
You do not need to abandon Controllers, Eloquent or Artisan. DDD helps you decide where business rules, use cases and infrastructure details should live when the application stops being a simple CRUD.
Start here
DDD is not about creating more folders.
It is about making the business language visible in the code. Instead of organizing everything only by technical type, you organize important parts of the system around business capabilities.
app/Modules/Billing/
├── Domain/
├── Application/
└── Infrastructure/Keeps one business capability together and makes the responsibility of each layer explicit.
Module
A module represents a business capability, such as Billing, Orders, Inventory or Customers.
Think business area, not just a folder.Domain
Where entities, value objects and business rules live. This layer should not know about Laravel or Eloquent.
Example: an Invoice decides whether it can be issued.Application
Where use cases coordinate the work: validate intention, call the domain, persist changes and return a result.
Example: IssueInvoiceHandler.Infrastructure
Where Laravel-specific details live: controllers, requests, Eloquent models, queues, integrations and adapters.
Laravel stays here, at the edges.
Laravel translation
Where does my usual Laravel code go?
The toolkit does not remove Laravel concepts. It gives each one a clearer architectural place.
What you know
Where it fits
Why
Controller
Infrastructure/Http
Receives HTTP input and calls a use case.
Service
Application/UseCases
Becomes a specific use case instead of a generic service full of unrelated methods.
Repository interface
Application/Ports/Out
Represents what the application needs from persistence without depending on Eloquent.
Eloquent Model
Infrastructure/Persistence
Handles database details at the infrastructure edge.
Business rule
Domain
Rules that define valid business behavior should stay close to the domain model.
Use this toolkit when...
The application has real business rules, multiple modules, long-term maintenance, integrations, or teams that need a shared architectural language.
Do not force it when...
You are building a tiny CRUD, a prototype, or a screen with no meaningful business behavior. Laravel's default structure may be enough.
02 · Architecture
A structure for
A structure for
serious Laravel apps.
This is not a replacement for Laravel's default architecture. Laravel remains excellent for simple CRUD and early-stage products. The toolkit shines when a system needs domain boundaries, stronger cohesion and protection against accidental coupling.
Execution flows inward. Dependencies point inward.
Domain
Entities, value objects and business rules
Application
Use cases and inbound/outbound ports
Infrastructure
Persistence adapters, Eloquent and integrations
Infrastructure/Http
Controllers and HTTP delivery concerns
Adapters
Ports
Use cases
DOMAIN
pure PHP
Built for complexity
Useful when controllers grow, generic services multiply, rules spread across the app and business modules start depending on each other.
Laravel stays Laravel
You still use the service container, Eloquent, events, jobs and testing tools — but from the right architectural edges.
A better team language
The structure makes discussions concrete: what is the module, the use case, the business rule, the port and the adapter?
03 · Getting started
From Composer to your first
From Composer to your first
domain boundary.
Install the toolkit, publish its setup and use the Artisan commands to discover and generate the pieces your application actually needs.
Terminal
✓
The toolkit adds structure without replacing the native Laravel workflow.
-
1
Install the package
Install the package from Packagist and check the GitHub repository for documentation and examples.
-
2
Prepare the project
Run the installer to publish configuration and align the initial folders with the selected architecture.
-
3
Create intentionally
Generate modules and use cases only when the application has real business boundaries to protect.
Command
Purpose
State
ddd:install
Publishes configuration and prepares the Laravel project for domain-oriented structure.
Readymake:module {name}
Creates a vertical module with hexagonal structure by default.
Readymake:port {module} {name} --type=out
Creates an outbound application port such as OrderRepository.
Readymake:adapter {module} {name} --port={port} --type=persistence
Creates an infrastructure adapter that implements a port.
Readymake:repository {module} {name}
Generates an infrastructure repository only when enabled in config or forced.
Opt-in
Usage example
A use case that speaks the language of the domain.
Controllers coordinate input. The use case executes the intention. The domain protects the rule.
HTTP Request→IssueInvoice→Invoice
IssueInvoice.php
04 · Community
Help mature the toolkit
Help mature the toolkit
with real Laravel pressure.
Contributions are especially valuable around documentation, release readiness, dependency hygiene, architectural checks and examples extracted from long-lived applications.