PHPackages                             mcgo/laravel-boundless - 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. [Framework](/categories/framework)
4. /
5. mcgo/laravel-boundless

ActiveLibrary[Framework](/categories/framework)

mcgo/laravel-boundless
======================

Laravel events without bindings. Freedom for your architecture.

1.1.0(7mo ago)01121MITPHPCI passing

Since Oct 10Pushed 7mo agoCompare

[ Source](https://github.com/McGo/laravel-boundless)[ Packagist](https://packagist.org/packages/mcgo/laravel-boundless)[ RSS](/packages/mcgo-laravel-boundless/feed)WikiDiscussions v1 Synced 1mo ago

READMEChangelog (2)Dependencies (2)Versions (3)Used By (1)

BoundLess
=========

[](#boundless)

Laravel events without bindings. Freedom for your architecture.

What and why?
-------------

[](#what-and-why)

Performing actions directly where things happen is not always the best way. Take a controller, for example. If you update a model in the controller, you could later do other things that are defined by your business logic, like adding some logging. Doing so in the controller might work, but what if the model is updated by another service?

Events with listeners or observers (aka the listener pattern) is a better way to do this. You can implement and register a `LoggingObserver` with a `saved` method for example. This method will then do the logging - even if the model is updated elsewhere. The code is a bit less coupled than in the controller, but it is still coupled to the model and laravel namespace.

But what if you plan to make it even a bit more loosely coupled? Maybe you even think about eliminating the direct implementation of the laravel namespace? Or using a microservice to perform the logging? This is where the BoundLess package comes in.

How?
----

[](#how)

The package aims to abstract the laravel internal listener pattern in two ways — with a little addon.

- the event name is not tied to a laravel class
- the payload is not tied to a laravel class
- BONUS: you could define how the event will be dispatched

Making it possible to implement a custom dispatcher, the limits are not within your laravel app, it is boundless. Think of emitting an event to a microservice via webhook.

How to use it?
--------------

[](#how-to-use-it)

### Installation

[](#installation)

Simply install the package via composer, the package uses some laravel classes, but it has no config, migrations or even a service provider.

`composer require mcgo/laravel-boundless`

### Usage

[](#usage)

Wherever you want to send an event, you can use the `McGo\BoundLess\Services\Boundless` class. It feels like a facade when using it:

```
use McGo\BoundLess\Services\BoundLess;
use App\Integration\BoundLess\DomainEventDefinition

BoundLess::init()
    ->forDefinition(DomainEventDefinition::class)
    ->dispatch();

```

This will use the `App\Integration\BoundLess\DomainEventDefinition` from your app to dispatch the event.

### Event definition

[](#event-definition)

Each event that you want to send should have a class that implements the `McGo\BoundLess\Contracts\ABoundLessEventDefinition`interface. The definition has two static functions, which define what event name will be propagated and how it will be dispatched. This could be in your app:

```