Install phpspec

The easiest rational way I know to expose SOLID principles violation is
through demonstrating communication of objects. The most straight
forward way to illustrate actual under-the-hood objects communication is
with any modern mockist framework. But because this project doesn't have
its own test suite, we'll start from installing our framework of choice

- We need PhpSpec to demonstrate mixture of concerns and SRP violation
- We need laravel/framework to fullfil Illuminate\Foundation\Application
  dependency
Describe ValidationCommandBus with examples

The next natural step is to actually describe object of interest
retrospectively. It is a tricky process on its own, but with some
experience and luck, we came up with something like this spec.
Comment responsibility groups

After writing usage examples of our ValidationCommandBus, we now can
clearly see two separate responsibility groups repeating in each of our
examples - command validation and handling.

Multiple responsibility groups usually hint towards SRP (Single
Responsibility Principle) violation. In our case - ValidationCommandBus
clearly knows not only how to create and use validator, but also how to
create and use command.

This issue is common when you use inheritance. Inheritance effectively
hides mixing of multiple concerns, hence the mantra "Composition over
inheritance".
Make ValidationCommandBus a decorator

We have a Single Responsibility Principle violation. Our command bus
attempts to implement new concern - command validation. But in addition
to doing that it also inherits original responsibility of
DefaultCommandBus.

Design patterns to the rescue! There is a wonderful design pattern that
suites such situations wonderfully well - Decorator. The core principle
of decorator is very simple - instead of extending class with basic
responsibility, we instead implement the same protocol (interface) that
base class implements:

    class DefaultCommandBus implements CommandBus
    class ValidationCommandBus implements CommandBus

making both classes implmenet same communication protocol. Next step is
composition. During construction of ValidationCommandBus we require
anything that implements our CommandBus interface:

    class ValidationCommandBus implements CommandBus {
        function __construct(CommandBus $bus, ...

to which we later delegate in custom ValidationCommandBus::execute:

    public function execute($command) {
        ...
        return $this->bus->execute($command);

This is "composition over inheritance". Because you compose your objects
in the runtime instead of coupling them in your codebase:

    $bus = new ValidationCommandBus(new DefaultCommandBus(...), ...);

Why is this implementation superior to version with inheritance? Well:

1. Because ValidationCommandBus does not depend on implementation of
   DefaultCommandBus, meaning you can change code of former any time
   without being afraid for horrible consequences.
2. Because it is much easier to explain, demonstrate and spec objects
   that have single responsibility over objects that inherit
   responsibilities from all over the system.
3. Because if you later want to introduce another responsibility to your
   bus, you still can do it:

       $bus = new LoggingCommandBus(
           new ValidationCommandBus(
               new DefaultCommandBus(...),
               ...
           ),
           ...
       )
Merge branch 'everzet-refactoring/real-decorators'
Add Artisan command for creating commands and handlers quickly
spacing
Update readme
Fix readme typo
Mustache should not be a dev requirement
Use correct class name
Update readme
Hide method visibility
Refactor command
visibility stuff
Fix class name
Fix nesting level regression - closes #16
Spacing
Refactor command
Fix class name