CQRS (Command and Query Responsibility Segregation) in PHP

Avi — Thu, 10 Dec 2009 20:57:54 +0000

It always seems to me that the PHP world is one step behind the current trends in the “enterprise world”. For example, Rails popularized the “ActiveRecord” pattern a few years ago. Ever since then, there has been an explosion of ActiveRecord implementations in PHP. Many even mistakenly refer to them as an “ORM”, but I won’t beat a dead horse here. ActiveRecord is great for your basic run-of-the-mill address book/cookbook/blog type of app, where it basically data driven, and there’s not much “business logic” to go around. For the majority of PHP applications out there, these tools are a god send.
As PHP matures, especially the object model, advanced developers have started to realize the limits of this pattern. Now the big rage is the DataMapper pattern, and DDD. We try to separate out the domain of application, and the holy grail is now transparent persistence. With great tools like Doctrine 2.0 and Object_Freezer, both of which are only possible with the new additions in PHP 5.3, these dreams are becoming a reality.

With this approach, which I have tried to follow recently, there are a couple of pointed issues. The biggest is displaying your domain objects. Off the bat, we don’t want to “pollute” our domain with display concerns (although one could argue that displaying the object is a business concern). So if we want to “drag the data” out of our domain, we need a lot of ugly “getters”, or to leverage the __get magic method. Getters have long been shunned for breaking encapsulation, revealing the “shape” of an entity (ie., it should not be so important to us that a customer has a first name), and some other things that don’t really apply in PHP land. But besides all that, they’re just so annoying to write.
Additionally, we don’t necessarily want to have our domain objects show up in our UI like that. The domain objects are not tailored made for consumption of our UI. There are many different presentation concerns such as, what I call the “Fowler Conundrum”, where do you specify that negative balances will show up in red, and positive in black? Do you create views which have all this ugly logic in them? Do you add it to your domain? Do you create a view helper for every little presentation concern? What about date formatting. Do you need to bring in a DateTime object in your view, and clutter it up with date formatting code? What if you only need a handful of fields to display…do we throw in the whole object to the UI and hope for the best?
The answer to this is to add an additional layer. The ViewModel. The ViewModel is shaped for every view in your UI. It contains all the necessary presentation logic.
The question still begs, how do you create these ViewModels? There’s basically three choices. Getters, displaying to an interface, and using Reflection. All of these feel like you’re compromising somewhere.
Another problem that I came up with recently is, how do you manage something like an autocomplete field. An autocomplete field takes the letters which have been typed in, and searches the database. So do I now need to search the database, get a bunch of domain objects, translate them in a ViewModel and send it back to the UI?
How about pagination? For efficiency purposes, we obviously want to paginate on the query level. We don’t want to bring in all our information, and then paginate that…it defeats (most of) the purpose. So do we have to pollute our repositories with findByPage methods? The other solution is almost as ugly (but it has a lot of elegance to it). In the .NET world, a proposed solution was to return an IQueryable…an interface that LINQ understands. The idea is, you’re repository returns an IQueryable (or even better, a special subset of IQueryable that you can call IPageable), and once you get that, you construct the rest of the information as gotten from the ui. This was debated upon for a long time whether 1) Whether this constitutes “pure DDD” and 2) Whether it is a good practice to begin with. The PHP version of this could be to return a Zend_Paginator_Adapter_Interface and basically do the same thing.
The latest “trend”, of which I don’t really see anybody speaking about in the PHP world, is that of CQRS. CQRS stands for Command and Query Responsibility Segregation, and it was formally known as CQS, or command query separation. CQS is a basic tenet of OOP, put forth by Bertand Meyer. The idea is simple, every method on an object is either a command (ie., it does something), or it is a query (ie., it retrieves information). A method should not do both (Martin Fowler admits that there are some compelling reasons to violate this, like popping a value from a stack, but in that case, the convenience outweighs the strict and blind adherence to principles).
In the past year of so, this pattern has been expanded on an architectural level. Meaning commands go to the domain, and queries go somewhere else. There are two parts of your system. The commands, which tell your system to do something, and the queries. The queries come from a query repository, which is a stale snapshot of the state of your entities. The commands go to a domain repository, which publish an internal event (which captures the business intent of the command), and an external event to update the data store.
The beauty of this, is that your view models don’t come from your domain anymore. They come from your query repository. You could retrieve them anyway you want (ORM, TableDataGateway, ActiveRecord or even straight SQL). In fact, the various views on your data could actually be real views in your database, denormalized to flatten relationships, or with only the fields that you need. Also, the internal published events can be stored in an EventStore, and played back to maintain the current state of the entity. This removes almost entirely the “impendence mismatch” between objects and the relational database.
I will hopefully right more on this pattern, and how it can be applied to PHP, as I learn more about it myself.

Aviblock.com » command query separation

CQRS (Command and Query Responsibility Segregation) in PHP