PHPackages                             ticaje/hexagonal - 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. ticaje/hexagonal

ActiveLibrary

ticaje/hexagonal
================

Library that defines hexagonal-design based policies

2.0.1(2w ago)0249↓100%OSL-3.0PHPPHP ^7.0 || ^8.0

Since Jul 24Pushed 2w agoCompare

[ Source](https://github.com/ticaje/Hexagonal-Design-Library)[ Packagist](https://packagist.org/packages/ticaje/hexagonal)[ RSS](/packages/ticaje-hexagonal/feed)WikiDiscussions master Synced today

READMEChangelogDependencies (7)Versions (13)Used By (0)

Hexagonal Approach Oriented Library
===================================

[](#hexagonal-approach-oriented-library)

[![GPLv3 License](https://camo.githubusercontent.com/19f3b8cdb6c4ca7671e1af3240e94eb087c2b0c1181a3357d8381af53c9d40cb/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6c6963656e73652d47504c76332d6d6172626c652e737667)](https://www.gnu.org/licenses/gpl-3.0.en.html)[![Latest Version on Packagist](https://camo.githubusercontent.com/ad84dd525560166b370f4daf0b8e11ffd17b3a9fec852098cb4986fea130ddcf/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f762f746963616a652f68657861676f6e616c2e7376673f7374796c653d666c61742d737175617265)](https://packagist.org/packages/ticaje/hexagonal)[![Quality Score](https://camo.githubusercontent.com/8bff1fec735d1691b5ebf190a853af0b3e525e83c89f092476076026898b83c7/68747470733a2f2f696d672e736869656c64732e696f2f7363727574696e697a65722f672f746963616a652f48657861676f6e616c2d44657369676e2d4c6962726172792e7376673f7374796c653d666c61742d737175617265)](https://scrutinizer-ci.com/g/ticaje/Hexagonal-Design-Library)[![Total Downloads](https://camo.githubusercontent.com/b7f58c17fb153a8c67330acc93acbc13f44a97a2cd001a4949891c6b07336d6a/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f64742f746963616a652f68657861676f6e616c2e7376673f7374796c653d666c61742d737175617265)](https://packagist.org/packages/ticaje/hexagonal)[![Author](https://camo.githubusercontent.com/3c3154e7d1e6e1d3c45389165493e28fc0279eced5a2b180bc66058f847196ff/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f48424c61746572616c2e636f6d2d2532333032313133613f7374796c653d6c6162656c436f6c6f723d6c6967687467726579)](https://hblateral.com)

Installation
------------

[](#installation)

You can install this package using composer(the only way i recommend)

```
composer require ticaje/hexagonal
```

Preface
-------

[](#preface)

This library settles the basis for a hexagonal-oriented-design based solutions. It is an API that encourages developers to use a Hexagonal design approach. We have wanted also to provide room for Command-Bus approach when exposing isolated services in a simple manner to consumers.

Hexagonal Architecture
----------------------

[](#hexagonal-architecture)

Also known as Port and Adapters, this design pattern is sort of a mindset applied to Software modeling when building scalable, testable and maintainable applications. It stands for a Way of Decoupling Software into smaller Units/Layers/APIs that can also be independently deploy-able and testable. Every one of those layers has its own boundary-oriented purpose whether in business or infrastructure grounds. Internet is full of articles and documentation about Hexagonal Design.

**So Port &amp; Adapters frame two important aspects to Software Design:**

**On one side there is the intention of creating aforementioned responsibility layers or APIs**

and on the other hand last but not least,

**the way those components interact with each other: these relationships are the core to Hexagonal cause they represent the real value of a Software.**

In reality, Hexagonal(like most of design patterns) is kind of abstract concept, there is no rule that says the pattern has been applied wrongly or properly.

### The preponderance of Interfaces

[](#the-preponderance-of-interfaces)

For me, and this is a personal opinion, the key to Hexagonal Architecture and to O.O.D in general is in Interfaces. Interfaces are everything to design's good decisions cause, amongst many other uses, they define the way applications interact with each others.

In Hexagonal context, Interfaces are ports that accept requests/data into our applications or APIs.

#### Interfaces in Hexagonal and S.O.L.I.D principles

[](#interfaces-in-hexagonal-and-solid-principles)

Interfaces are the key to **D** in **SOLID** principles Dependency Inversion Principle establishes that high level modules should not depend on low level modules, and both must depend on abstractions; also abstractions should not depend on details but the other way around, details should depend on abstractions.

This sounds kind of ethereal but it has all the sense of the world in terms of Hexagonal standpoint. the way all of our APIs define and present themselves to the world should be by using ports whose entry points are interfaces, then following points would be guaranteed:

1. **Multiple Implementations** on all sides, every module uses adapters(different implementations for every interface).
2. **Change encapsulation**: modules remain unalterable to change of other modules since they correlate via interfaces(abstractions)
3. **Law of Demeter**: every module has minimal knowledge of the rest of modules, it only knows what is defined on their service/data contract within the Interfaces themselves. This is quite important cause it normalizes the communications between agencies.
4. **Simpler Testing**: Testing classes/APIs/modules/agencies with little(essential) responsibilities turns out to be much simpler and hence our application more maintainable.

Essentially, Hexagonal architecture is about using interfaces(or equivalents) and abstractions thoroughly to build relationships amongst system components in the same way a writer creates a novel and profiles characters/stories/timelines in a credible construction to readers. so the purpose of Hexagonal is to communicate system intention in a good story at the same time that good design principles are achieved.

So Interfaces(Ports) reflect intention and concrete Implementations(Adapters) provide fluent/interchangeable solutions.

Command Bus Approach
--------------------

[](#command-bus-approach)

This design pattern is present also in this library cause it can be included in Domain modeling along with Hexagonal design.

The idea behind Command Bus is **having a Command entity(that describes what specific actor wants) and map it to a Handler entity that executes it**. That's it.

This is especially useful when having Service layers that are consumed by other modules, whether high or low level modules.

For this library we are leaning on useful library that is in charge of machinery gearing when it comes to finding handlers for corresponding commands: [Tactician](https://tactician.thephpleague.com/) takes care of that for us.

We have created a Specific implementor that connects to our Port: BusFacadeInterface via constructor as ImplementorInterface. Then in a DIC the wiring up is completed.

Example in Laravel(via Contextual Binding).

Imagine we want to inject our Bus implementation to a specific controller in Laravel application, then we just need to inject ImplementorInterface within its constructor and define the recipe in DIC as something like following snippet:

```
$this->app->when(ConsumerController::class)
          ->needs(ImplementorInterface::class)
          ->give(function ($app) {
              return ($app->make(Tactician::class));
});
```

A pretty good example of Command-Bus in practice could be having a service that can be consumed by multiple contexts.

Imagine that we have a price API that provides prices according specific business rules.

This API could be consumed from many contexts: Http call, cli command, another API or Message Queue based application

Well, as we can see there must be a unique place where all calls can rely on. Applying Command-Buss approach makes it really simple just by defining a command that is essentially a DTO that contains all necessary data for the service to operate according business policies and pass that command off to the handler that is actually the actor that wraps the service in stake and launches its logic.

The Bus is the guy in charge of finding the handler for specific command.

This simplifies the machinery of consuming services since all consumers just need to prepare the Command, instantiate the bus and call its API(sending the command as parameter) to consume the desired service.

Credits
-------

[](#credits)

- [Héctor Luis Barrientos](https://github.com/ticaje)
- [All Contributors](../../contributors)

License
-------

[](#license)

The GNU General Public License (GPLv3). Please see [License File](LICENSE.md) for more information.

###  Health Score

48

—

FairBetter than 95% of packages

Maintenance96

Actively maintained with recent releases

Popularity12

Limited adoption so far

Community6

Small or concentrated contributor base

Maturity66

Established project with proven stability

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~186 days

Recently: every ~291 days

Total

12

Last Release

18d ago

Major Versions

1.0.9 → 2.0.02025-03-27

PHP version history (3 changes)1.0.0PHP ^7.1

1.0.6PHP ^7.0

2.0.0PHP ^7.0 || ^8.0

### Community

Maintainers

![](https://www.gravatar.com/avatar/972ffc9fba0b074b4bd8c9550ff68cea1c8ddcd9e5f7b21980257eaa4e582720?d=identicon)[ticaje](/maintainers/ticaje)

---

Top Contributors

[![ticaje](https://avatars.githubusercontent.com/u/1042962?v=4)](https://github.com/ticaje "ticaje (10 commits)")

---

Tags

Domain Driven DesignhexagonalDesign by contractPort and Adapters

###  Code Quality

TestsPHPUnit

Code StylePHP CS Fixer

### Embed Badge

![Health badge](/badges/ticaje-hexagonal/health.svg)

```
[![Health](https://phpackages.com/badges/ticaje-hexagonal/health.svg)](https://phpackages.com/packages/ticaje-hexagonal)
```

###  Alternatives

[broadway/broadway

Infrastructure and testing helpers for creating CQRS and event sourced applications.

1.5k1.9M48](/packages/broadway-broadway)[qossmic/rich-model-forms-bundle

Provides additional data mapper options that ease the use of the Symfony Form component with rich models.

218276.6k](/packages/qossmic-rich-model-forms-bundle)[broadway/broadway-bundle

Symfony bundle for broadway/broadway.

68848.8k7](/packages/broadway-broadway-bundle)[phpmentors/domain-kata

Kata for domain models

73420.9k9](/packages/phpmentors-domain-kata)[lunarstorm/laravel-ddd

A Laravel toolkit for Domain Driven Design patterns

17552.1k](/packages/lunarstorm-laravel-ddd)[thejano/laravel-domain-driven-design

Helps to use domain driven design within laravel

15322.7k](/packages/thejano-laravel-domain-driven-design)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)
