On his site Ross Tuck has a post that covers a common design pattern, the Command Bus, how it relates to CQRS and that they shouldn't return anything. In the post he takes some of the most common questions about using a command bus and tries to clarify with the correct answer.

The most common question I get about my command bus library is: “can commands really return nothing?” The second most common question is “Why do you let commands return something, don’t you know that’s Wrong(tm)?”

It’s easy to get hung up on form, not function. That’s a shame because command buses aren’t important. In the grand scheme of things, they’re completely, utterly, totally unimportant. It’s all about where the messages are going, not how they get there.

Still, let’s take a look at some myths about command buses.

The questions he tackles include topics like the relationship between CQRS and command buses, if you should be using them together (dependencies) and some discussion about return values and the "right" way to do things.

Continuing on from the first part of the series Loïc Faugeron has posted the next tutorial in the "PragmatiClean" series covering the use of the Command Bus pattern in your application.

The Command Bus pattern relies on 3 types of classes:

The first one is the Command [...] next is the Command Handler [and] finally there's a Command Bus interface allowing us to build Middlewares.

For each of these parts of the design pattern he covers what the part is and how it fits into the overall structure the pattern defines. He also looks at how it allows for easier adherence to the ideas of both "clean" and "pragmatic" code. The post ends with an example of implementing the Command Bus pattern in a Symfony-based application, building out each part and their integration.

Loïc Faugeron has posted the latest in his "Mars Rover" tutorial series to his site today. In this new post he migrates some previously created objects over into their own package to help with reporting back the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location. In this article we're going to move geolocation value objects (Location, Coordinates and Orientation) into their new package (geolocation).

He then moves over the files relating to these objects into the "Geolocation" directory and fixed the namespace to reflect the update. Tests are all still passing so he moves over to the "navigation" package and fixes a few places in the tests where these objects were mentioned (doing the same for the "orientation" handling). This finishes out the series with a complete set of classes and objects reflecting the requirements. He summarises the work that was done, how the resulting code is structured and the major role that the phpspec testing played in the whole process.

In this latest post in the series Loïc Faugeron continues his "Mars Rover" tutorials, this time with a focus on creating the logic that will "drive" the rover around.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD).

We've already developed the first use case about landing the rover on mars, and we've started the second one about driving it. [...] In this article we're going to create the actual driving logic, using Event Sourcing.

He follows the "Command Bus" design pattern and creates the command structure for the DriveRoverHandler to handle the logic related to the DriveRover instance. He starts with the spec (the test) and updates the generated class with the logic in the handle method to record an event happening on the DriveRover instance. He make a few more changes to the functionality for the spec and class to make the tests go green.

In this recent post to his site Robert Basic shares some of his experience integrating the Tactician command bus library into a Zend Expressive-based application.

I spent some time connecting the dots last week, so I decided to put together an example on how to get started with using Tactician in a Zend Expressive application. The example itself is not really useful, but it does show how to setup the dependencies and get started with these two libraries.

He briefly introduces the two pieces of technology here and then "dives in" immediately to the integration. He shows how, using the Zend Expressive skeleton application, to expand on the default "ping" endpoint and add in the Tactician library (and another library that makes it easily integrate with the DI container). He updates how the "ping" action is made in the routing, making it go through a factory. He then brings Tactician in, setting up the command bus and a simple "ping" command for the bus to use in handling the requests to the /api/ping endpoint. Complete code and explanations of each part are included in the tutorial to help you follow along.

Loïc Faugeron has made a new post to his site talking about moving towards CQRS and Command Bus architecture in PHP applications.

By following the Command / Query Responsibility Segregation (CQRS) principle, we separate "write" logic from "read" logic. This can be applied on many levels, for example on the macro one we can have a single "Publisher" server (write) with many "Subscribers" servers (read), and on a micro level we can use this principle to keep our controllers small.

However, transitioning from a regular mindset to a CQRS one can be difficult. In this article, we'll explore the "Command Bus" pattern, to help us to get the Command (write) part right.

He starts with an example of a "create profile" happens and all logic lives in the controller. He then gets into the basics of the Command Bus handling and how the concept of "middleware" relates. He then shows how to migrate over to the Command Bus handling in his controller example, creating a CreateNewProfile command (with unit tests) and its handler. He then refactors the controller to put it to use. He points out that the initial version is tightly coupled to Doctrine so he refactors it too via some simple interfaces.

In this post to his site Paul Jones looks at the combination of the Action-Domain-Responder pattern and the Command Bus pattern in application development. In the post he answer the question about how they fit together.

Over the past few weeks, different people have asked me where a Command Bus goes in an Action-Domain-Responder system. While I’m not a DDD expert, after brushing up on the subject a little, my answer is: "In the Domain."

He starts by reviewing the three pieces of the ADR pattern with brief descriptions of each. The then covers the Command Bus pattern, linking to several other resources with more details about the pattern itself and a quick summary of their main points. He talks about how the overall structure is a part of the Command Query Responsibility Segregation pattern and suggests that, since the Command Bus pattern is a "fire and forget" kind of thing it belongs in the Domain of ADR. He gives a brief code example and answers other questions about validation and error handling as a part of this suggested flow.

On the SitePoint PHP blog there's a tutorial posted that wants to help demystify the command bus design pattern with the help of the Tactician package, a part of the packages from The PHP League.

Command Buses have been getting a lot of community attention lately. The topic can be quite overwhelming at first when trying to understand all the concepts and terminology, but in essence – what a Command Bus does is actually incredibly simple.

In this article, we’ll take a closer look at variations of the Command Pattern; their components; what a Command Bus is; and an example application using the Tactician package.

The article starts with a look at what the Command Bus design pattern is and where it could be put to use in an application. There's a bit of sample code showing how to implement a basic bus and the commands it would be used to execute. Their example application uses a "deck of cards" set of actions. They show how to use the Tactician library to build and execute three related commands: CreateDeck, ShuffleDeck and DrawCard. They show you how to build out the pieces you'll need - the extractor, locator and middleware - and join them all together to execute the commands.

In a post to the Madewithlove blog Maxime Fabre takes a look at threading in PHP using the pthreads support that can be included into your PHP installation.

As far as I can remember, PHP has always had a terrible reputation at handling very heavy (or asynchronous) tasks. [...] But PHP can do threading, and more importantly it's a lot easier than you probably think.

[...] In this article I'm going to dive into the pthreads extension (short for POSIX Threads). It has been around for a while (since 2012) but I feel like too many people forget it exists or assume it is going to be painful to use – mostly because the official documentation is rather slim about it.

They start by getting the pthreads support installed locally (it assumes you use OS X and the "brew" package manager but it can be installed manually too). The article starts off by defining some basic nomenclature from the pthreads world and gives a diagram of how it all fits together. From there it gets into some examples, showing a simple thread class to fetch Google results and how to fire off multiple instances at the same time. They then extend this even further and look at the concept of "workers" and using them to manage individual jobs. It then moves up the next level and looks at "pools" of workers and processing multiple workers at the same time.

There's also a section dealing with one "gotcha" that can happen with class inheritance between parent and child threads. They show how to work around this with a custom Worker class that performs the autoloading for you and is executed at the start of a Pool. Finally they cover the messaging between the child threads and, as a bonus, how threading could be used in a command bus setup.

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.