PHPackages                             ylsalame/laravel-use-cases - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. ylsalame/laravel-use-cases

ActiveLibrary[Utility & Helpers](/categories/utility)

ylsalame/laravel-use-cases
==========================

A reusable UseCase pattern implementation for Laravel applications, including a base UseCase, class inference helper, execution context and an extendable controller.

0.3(2mo ago)030MITPHPPHP ^8.2

Since Feb 17Pushed 3mo agoCompare

[ Source](https://github.com/ylsalame/laravel-use-cases)[ Packagist](https://packagist.org/packages/ylsalame/laravel-use-cases)[ RSS](/packages/ylsalame-laravel-use-cases/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (2)Dependencies (12)Versions (4)Used By (0)

App\\UseCases Rules
===================

[](#appusecases-rules)

General Principles
------------------

[](#general-principles)

UseCases are single-use, business-logic oriented and self-contained functionality holders. They are intended to provide the **lowest denominator** of a business logic to make system maintenance easy, simple and straight-forward

Request lifecycle
-----------------

[](#request-lifecycle)

Using Laravel you would normally have an endpoint that when hit, triggers a Controller that then distributes the workload of validation, UI management, bussiness rules, error handling and response structure.

What this library aims to do is to simplify this lifecycle by abstracting the most common elements of it and delegating them to their responsible classes albeit automatically. It aims to make things as DRY and simple as possible.

Folder+File Structure
---------------------

[](#folderfile-structure)

UseCases are stored in `/app/UseCases/` under folders that group their target/entity eg.: `Webhooks/`, `Events/`, `Project/`, `Model/`, etc.

A UseCase file/class should be named after their object+action

- File naming: `{object}{action}UseCase.php` (e.g., `ProjectCreateUseCase.php`)
- Class naming: `{object}{action}UseCase` (e.g., `ProjectCreateUseCase`)

The naming convention plays a part into the automation of the file structure and associated responsabilities.

So we have:

- Endpoint management (Route)
- Entry point (Controller)
- Validation (Form Request)
- Business Rules (Use Case)
- Output formatting (Resource)

This should translate into:

- /routes/api.php
- /app/Http/Controllers/ExampleController.php
- /app/Requests/Example/ExamplePingRequest.php
- /app/UseCases/Example/ExamplePingUseCase.php
- /app/Resources/Example/ExamplePingResource.php

Clean code and DRY implementation
---------------------------------

[](#clean-code-and-dry-implementation)

DRY Implementation allows us to avoid having to rewrite multiple parts of our code. If you adhere to the naming conventions the non-bussiness logic is taken care of for you.

In the Route you will do the same thing you always did before. Asign a controller+method to an endpoint.

In a UseCase you will:

- extend the BaseUseCase from this package
- not have to use transactions since they are built in
- not have to validate the data since the Form Request is triggered before the Use Case is
- not have to call the Resource to format the response since anything you return from the Use Case is piped into the Resource already

In a Controller you will:

- extend the BaseController from this package
- not have to add any code to it -- the Use Case will be called based on the naming conventions -- the data sent from the endpoint URL will be appeneded to the data sent to the Use Case -- the Form Request will be triggered passing the data collated for the request

Example Code
------------

[](#example-code)

With the premise that I want to fetch the list of Users from an application:

The /routes/api.php routes file:

```