Why should you use CommandBus

CommandBus and CQ(R)S are gaining a lot of popularity over last year. Today I got question about benefits of the switch. As I used it by default for last year I’ve never thought about it. I’ll try summarize it in this article and in next one I’ll explain how you can change your architecture in life project in reasonable and production safe way. Let’s get to it!

Why should you use CommandBus

CQS stands for Command Query Separation. Simple as it is – every operation which is not just read in encapsulated in Command and handled by CommandHandler. The biggest benefit of that approach is that you have each business operation in separate class. Thanks to that when change has to be made it’s very clear where it should be done and when new feature comes in it won’t interfere with what you already have.

Second argument is very close with first and it’s about communication between dev team and business. Each handler is one specific case and it’s name reflects business language more than what dev team thinks it is. You’re dropping meaningless .*Service classes which grows out of reasonable size very fast.

Stopping unreasonable growth is part of Solid. Single responsibility principle says that each class should have specific functionality. Keeping separate handlers is the best way for that.

Very important in all of that is separation between input and business logic. All you can do outside CommandBus is to create and validate command and send it through with bus. Your controllers are getting very thin and probably you can do half of the things automatically even before it. You also stopping to care where and how command is created. You can execute the same operation from many places without any modifications in your business code.

Cherry on top when you’re creating any API is that you can deserialize your input whatever it is (JSON/XML) straight to object of the command. It saves a lot of time, especially with Symfony 2 where you can create very neat ParamConverter to do the thing for you and throw 400 if validation fails.


Let’s take UserService from thin controller fat service architecture. You have there two methods – registerUser and updateUser. First one creates user and sends confirmation email. Second just updates fields in User.

First thing broken is SOLID as two operations are handled by the same class. You also have to have dependency on some mailer to be able to send email during registration. But do you need to instantiate it when updating user? No. So we can assume you’re looting time and resources on every update of the user.

Question also is – WTF is “updateUser” – which business process is it? When user changes email? When user changes password? When user is promoted to different role?

Usually all from above processes will use this method and you will have lovely stack of ifs to determine when you have to send confirmation of new email, encode password or just update column with role value. Or even worse you’ll have event listeners on specific fields hidden somewhere deep in code and first new person will add another one because of no knowledge of old ones and after another month you will be adding parameters to enforce listeners to be fired in proper order.

Been there done that ;)

With each process in different class you’re avoiding all of that. You’re doing your tasks with speed and precision saving your time and business money.

Stateless authentication in Symfony 2

Everyone these days want’s an API. Mostly for some SPAs or for external applications. Common issue here is a security layer where you can’t use standard form and cookies. Other thing about state saved in cookies is f.ex. clickjacking. James Ward wrote about this some time ago.

So we have some requirements:

  • Authentication based on token
  • Token is send as part of each request to make API stateless
  • I want to be able to use Symfony Security layer as I do in “normal” applications
  • Bonus: I want authenticate each device with different token (when someone is using app on PC and phone in the same time)

So I went to Symfony Cookbook and I’ve found solution with my requirement in the title. And it wasn’t what I needed. OK, it’s about keys/tokens and probably I could make it working but I have a lot of free time during holidays so I can do better. So I went one article further to write my my own authentication provider. And there is of course article about it too.

Lets start with UserProvider. What I want is find User entity with given token and device identifier. Simple schema looks like this:

User and Identities

To find user I query by username when authenticating user by token and device on the beginning of each request and once in a while by username and password to create new Identity.

Interface like this is everything I need and it’s consistent with Liskov’s substitution principle (L in SOLID).

When I can find user all I need is follow Cookbook and everything is working great. SecureApiBundle is available on GitHub so you can check how I’ve done this.

Update your composer.json file

enable it

and use secure-api in your security config:

I know it is possible to add paths for registration and session creation to config, but for now I don’t need this so I keep it simple :P Doctrine UserRepository is used here as User Provider with interface I mentioned earlier. Line 28 is marker that we are using our token solution for this firewall.