That Podcast, with hosts and PHP community members Beau Simensen and Dave Marshall, has posted their latest episode: Episode #50 - Episode 50: The One Where We Talk to Shawn about Event Sourcery, CQRS, Event Sourcing and GDPR

In this episode, Dave and Beau talk to Shawn McCool about his experiences with CQRS and Event Sourcing, the GDPR, and his recently revealed open source project event sourcery.

Event sourcery is a PHP CQRS/ES library with a core principle of keeping it simple, while providing some more advanced technical capabilities, like keeping personal data out of the immutable event streams.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3 of the show directly. If you enjoy the show be sure to subscribe to their feed and follow them on Twitter for updates on when new shows are released.

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.

Matthias Noback has posted about CQRS (Command Query Responsibility Segregation) on his site showing how to reduce coupling and let the "model(s) evolve" that tries to break down some of the perceived complexity around the design technique.

CQRS has some reputation issues. Mainly, people will feel that it's too complicated to apply in their current projects. It will often be considered over-engineering. I think CQRS is simply misunderstood, which is the reason many people will not choose it as a design technique.

[...] CQRS alone simply means that you're making a distinction between a model that is used for changing state, and a model that is used for querying state. In fact, there's often one model that accepts "write" operations (called "write model" or "command model") and multiple models that can be used to "read" information from (called "read models", or "query models").

He goes on to talk about the more common structure in applications, a single model that handles all of the usual CRUD operations rather than having it split up. He then moves on to the topic of coupling and reducing it through the use of read-only models. He shows examples of the code for these models as well as tips for dealing with inconsistent data.

Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

• Test Coverage
• Domain-driven design
• Frameworks
• Event sourcing + CQRS
• Pair programming
• Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

Loïc Faugeron has posted the latest part of his "Mars Rover" series documenting the creation of a system to control a rover following the ideas of Monolithic Repositories, Command / Query Responsibility Segregation, Event Sourcing and Test Driven Development (using phpspec). In his previous posts he set up the project and created the package for navigation. in this latest post he gets into the navigation package.

Previously we've created a navigation package, we can now start developing the first use case:

Mars Rovers need first to be landed at a given position. A position is composed of coordinates (x and y, which are both integers) and an orientation (a string being one of north, east, west or south).

He starts off with using the Command Bus pattern to create a command, a handler and a bus that acts on the commands given. True to TDD he starts with the tests and fills in the code to make it all work. This generates the skeleton class for the test which is then filled in with functionality. Running the tests again then has them all passing once a few more changes are made to the internal handling (besides just the basics).

Loïc Faugeron has posted the next part of his "Mars Rover" series with the initialization of the project and taking some first steps with modules.

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

But first, we need to initialize our project.

He walks through the creation of the initial repository with a composer.json configuration and commits the initial version. From there he creates the "navigation" package that will handle write-only and read-only functionality to "drive" the rover around. He creates this package and a matching phpspec configuration file for testing the codebase. He then adds the navigation package to the main project though a branch merge.

Loïc Faugeron has started off a new series of posts with an introduction to a "Mars Rover" exercise that aims to help you refactor a "monolithic" codebase with CQRS, event sourcing and TDD practices.

In this introductory article, we're simply going to describe our Mars Rover specifications.

Note: This programming exercise originally comes from Dallas Hack Club, which is now unfortunately down. This Mars Rover kata has been adapted for the needs of this series.

He starts by outlining the goals the software will need to achieve and the complete functionality to provide. This is just the series kickoff though, so there's not much by way of code. Next in the series is the "MonoRepo" section and the setup of the actual project.

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.

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.