What this prompt does
This prompt asks the AI to implement the service and repository pattern for one business domain in a Laravel app, producing the full set of layers rather than a single class. It generates a repository interface and Eloquent implementation, a service holding the business logic, DTOs for moving data between layers, a service provider binding for dependency injection, a refactored controller that delegates to the service, Form Request validation, and both unit and integration tests.
The variables define the shape of the architecture. [domain] names the business area, [model_name] is the primary Eloquent model the repository wraps, and [business_operations] lists the operations the service must expose — these become its public methods. [architecture_style] sets the guiding principles (clean architecture with SOLID), which influences how strictly the layers are separated. Because the prompt treats DTOs and Form Requests as the contract between layers and asks for a mocked-repository unit test plus a real integration test, the output is testable by design rather than tangled controller logic.
When to use it
- Pulling business logic out of fat controllers into a dedicated service layer
- Establishing a repository abstraction so the rest of the app doesn't query Eloquent directly
- Setting up a new domain in a growing Laravel app that needs clear boundaries
- Making business logic unit-testable by mocking the data layer
- Introducing DTOs as an explicit contract between controllers, services, and repositories
- Standardizing how a team structures non-trivial features going forward
Example output
You get a stack of PHP files: an interface plus its Eloquent repository, a service class whose methods map to your [business_operations], DTO classes, a service provider registering the interface-to-implementation binding, a slimmed-down controller, Form Requests, and two test files — a unit test with a mocked repository and an integration test hitting the database. Custom exceptions handle error cases. The controller becomes thin, delegating to the service, which orchestrates the repository and returns DTOs.
Pro tips
- Name
[business_operations]precisely (create order, process payment, generate invoice) — each becomes a service method, so vague lists give vague services - Keep one repository per
[model_name]; resist letting a service reach across many models, which erodes the boundary you're building - Use the DTOs as the real contract — don't let raw Eloquent models leak through the service into controllers
- Register the interface binding in the generated service provider and confirm it resolves before writing more code against it
- Treat the mocked-repository unit test as the spec for your service's behavior, and the integration test as proof the Eloquent layer actually works
- Don't over-apply this to trivial CRUD; the pattern earns its keep on domains with real business rules, not simple lookups
