We’re moving datastore events out of the database layer and into the datastore layer while also splitting operation traits into paired versions (with and without events) to give developers more control over event emission. This change breaks backward compatibility but creates a more flexible, truly nomadic system where developers can choose exactly which operations should emit events rather than being forced into a one-size-fits-all approach.

I have come to realize it’s likely time to pivot away from PHPNomad’s simple container system, and embrace integrating with existing solutions, instead.

Currently, event bindings are supported using a callback. Ready::class => [ [‘action’ => ‘init’, ‘transformer’ => function () { $ready = null; if (!self::$initRan) { $ready = new Ready(); self::$initRan = true; } return $ready; }] ], This tends to be overly terse, and require calls like this in cases where you want to encapsulate the logic: $saleTransformerCallback = fn($orderId, $orderData) => $this->container->get( SaleTriggeredTransformer::class )->getSaleTriggeredEvent($orderId, $orderData); SaleTriggered::class => [ [‘action’ => ‘action’, ‘transformer’ => $saleTransformerCallback], ], It would be much nicer if it were possible to do this, instead: SaleTriggered::class => [ [‘action’ => ‘action’, ‘transformer’ => SaleTriggeredTransformer::class], ], Would…

Why We’re Saying Goodbye to Mutators The Mutator package, while well-intentioned, has become a source of unnecessary complexity in our development workflow. What started as an attempt to create a flexible data transformation system has instead created a maze of interfaces, adapters, and callbacks that obscure the true intent of our code. The Problem with Mutators Our current Mutator pattern introduces: A Better Path: Event-Driven Mutations Instead of wrestling with complex Mutator interfaces, we’re embracing a more intuitive approach: Simple, Direct Event Transformations class UserRegisteredEvent implements Event { private string $email; private string $name; public function setEmail(string $email): self {…

The heart of the nomadic approach is that your code should be free to travel and adapt, like a digital nomad who can work from anywhere. The existence of a core package actually contradicts this fundamental principle. Here’s why: The solution is to break down the core package into focused, independent tools that developers can use as needed. Each piece should solve a specific problem in making code more portable, without creating dependencies on PHPNomad itself. Think of PHPNomad more like a travel guide than a destination. It should show you how to write code that can travel well, not…

Current Implementation PHPNomad currently uses a Facade pattern implemented through abstract classes to provide static access to services. Facades serve two primary purposes: The current implementation requires: Challenges Architectural Limitations Impact on PHPNomad’s Core Philosophy The current Facade implementation conflicts with PHPNomad’s goal of writing truly portable code. By relying on global state and single container context, we limit the ability for code to be truly “nomadic” and run anywhere. Proposed Solution New Facade Pattern Instead of using abstract classes and global state, we propose a new pattern that: Implementation Details class LoggerFacade { use WithFacadeCapability; protected static function getRequiredType():…