1

When designing an application's back-end you will often need to abstract the systems that do things from the systems that actually do them.

There are elements of this in the CQRS and PubSub design patterns.


By way of example:

  • A new user submits a registration form
  • Your application receives that data and pushes out a message saying “hey i have some new user data, please do something with this”
  • A listener / handler / service grabs the data and processes it

(please let me know if that makes no sense)


In my applications I would usually:

  • Fire a new Event that a Listener is set up to process Event::fire('user.new', $data)
  • Create a new Command with the data, which is bound to a CommandHandler new NewUserCommand($data)
  • Call a method in a Service and pass in the data UserService::newUser($data)

While these are nearly exactly the same, I am just wondering - how do you go about deciding which one to use when you are creating the architecture of your applications?

MrSunshine
  • 95
  • 3
  • 7

1 Answers1

2

Fire a new Event that a Listener is set up to process Event::fire('user.new', $data)

Event pattern implies that there could be many handlers, subscribing to the same event and those handlers are disconnected form the sender. Also event handlers usually do not return information to the sender (because there can be actually many handlers and there is a confusion about whose information to return).

So, this is not your case.

Create a new Command with the data, which is bound to a CommandHandler new NewUserCommand($data)

Commands are an extended way to perform some operation. They can be dispatched, pipelined, queued etc. If you don't need all that capabilities, why to complicate things?

Call a method in a Service and pass in the data UserService::newUser($data)

Well, this is the most suitable thing for your case, isn't it?

While these are nearly exactly the same, I am just wondering - how do you go about deciding which one to use when you are creating the architecture of your applications?

Easy. From many solutions choose only those, which:

  • metaphorically suitable (do not use events, where your logic does not look like an event)
  • the simplest (do not go too deep into the depths of programming theories and methods. Always choose solution, that lowers your project development complexity)

When to use command over event?

Command: when I have some single isolated action with few dependencies which must be called from different application parts. The closest analogue is some editor command, which is accessible both from toolbar and menu.

Event: when I have several (at least in perspective) dependent actions, which may be called before/after some other action is executed. For example, if you have a number of services, you can use events to perform cache invalidation for them. Service, that changes a particular object emits "IChangedObject" event. Other services subscribe to such events and respond to them invalidating their cache.

Vladislav Rastrusny
  • 29,378
  • 23
  • 95
  • 156
  • That is great, thank you so much for explaining your thinking behind each. Could you give an example of when you would use the Command or Event pattern. Getting to understand the subtleties will help me a lot. – MrSunshine Mar 27 '15 at 07:12