Matthias Noback has posted about some of his experimentation with Broadway, a framework of testing helpers and structure to create CQRS/event sourced applications. CQRS is a design pattern (Command Query Responsibility Segregation) that essentially defines the use of a different method for reading data than for working with it (ex: updates or creates).

At the Dutch PHP Conference I attended a workshop by Beau Simensen and Willem-Jan Zijderveld. They showed us some examples of how to work with Broadway, a framework for event sourcing, with full Symfony integration, created by the smart people at Qandidate.

During my two weeks of funemployment, before starting my new job at Ibuildings, I decided to recreate one of my previous projects using Broadway. As it turns out, it's a great framework that's quite easy to use and is very powerful at the same time. Even though it's not a stable package (as in, it's still in the 0.x version range), I think it's safe to depend on it.

Matthias found that one of the main features of the models in Broadway is the serialization of them for storage, but wanted to reduce the amount of time to handle that...so he created this library. He also talks about something that several have pointed out as missing in the Broadway structure: how to use "sagas". He ends the post with an update on his own tool, SimpleBus, that handles eventing and via message busses, noting that it's not going anywhere but if you use Broadway, there's no reason to use SimpleBus too.

The Sound of Symfony podcast has released their latest episode today, episode #8 - Concerning command buses with hosts Magnus Nordlander and Tobias Nyholm and special guest Matthias Noback.

In this episode we talk to Matthias Noback about command-query separation, command buses, hexagonal architecture, REST and his library SimpleBus.

You can listen to this latest episode either through the in-page player or by downloading the mp3 of the show. If you enjoy the topic or the show be sure to also subscribe to their feed to get this and future episodes as they're released.

Matthias Noback is back with another post in a series looking at using a command bus to execute more complex code in somewhat of an isolation from the rest of the application. In this new post he moves on to some of the secondary tasks that happen inside the commands and how those relate to event handling.

In the previous posts we looked at commands and the command bus. Commands are simple objects which express a user's intention to change something. Internally, the command object is handed over to the command bus, which performs the change that has been requested. While it eventually delegates this task to a dedicated command handler, it also takes care of several other things, like wrapping the command execution in a database transaction and protecting the original order of commands.

He gets into some of these secondary tasks inside of the commands themselves - smaller actions that need to be done as a part of the execution of the command as a whole. He points out that it's tempting to do everything inside the command, but that it can lead to maintenance issues down the line. He suggests that the command shouldn't perform these tasks at all. They should be handled by an event system that uses event objects to pass off responsibility for performing actions to other objects (for example, handling the post-signup process once a user is created). He's done some research on some event dispatchers currently available but found them lacking in one way or another. Instead he opted to integrate one into his SimpleBus library (EventBus) to provide an integrated way of handling these secondary events. An example of it in use is also included.

Mathias Noback has posted another in his series looking at the concepts and implementation of command bus handling in PHP. In this new post he looks at some of the responsibilities of the bus and provides a few examples to help drive the point home.

In the previous post we looked at commands and how you can use them to separate technical aspects of the input, from the actual behavior of your application. Commands are simple objects, handed over to the command bus, which performs the change that is needed. [...] So the command bus contains some kind of a lookup mechanism to match commands with their handlers. Some command bus libraries use a naming convention here (e.g. handler name = command name + "Handler"), some use a kind of service locator, etc.

He starts off talking about the main point of the article, giving an overview of what he sees are the basic responsibilities of the command bus. He also sheds some light on methods he's seen for keeping it from becoming a "big inarticulate unmaintainable class". He then gets into his two examples: database transaction handling and protecting the original order of commands. He shows how his SimpleBus package handles most of this for you and shows how it follows the "chain of responsibility" design pattern to make it work.

In his latest post Matthias Noback looks at the recent interest in command bus handling in the PHP community. He introduces the concept for those not familiar with it and how it's handled in most of the command libraries.

Recently many people in the PHP community have been discussing a thing called the "command bus". The Laravel framework nowadays contains an implementation of a command bus and people have been talking about it in several vodcasts. [...] Since I consider this topic to be a very important and highly relevant one, I will spend several blog posts on it, explaining the concepts in my own terms, then introducing SimpleBus as a ready-made solution for your everyday PHP projects.

He starts with the definition of a command as something used "separate the technical aspects of user input from their meaning inside the application", a request from the client for the application to perform a task. He gives a simple example of a command (SignUp) and how it would be sent to the bus for handling. He lists some of the advantages of using commands like this, including the separation it allows between things like controllers and the actual functionality. He finishes up the post with a look at the actual command handler (with sample code) and the one-to-one relationship they have with the actual command.

Using commands you can separate the web-specific parts of your application from its essence. Commands define the use cases of your application and provide an internal API for anyone that might want to do something with your application.