So you’ve just learned Akka and are tremendously excited. It’s got dispatchers, routers, supervisors - so many shiny things to play with, and in style (I mean, come on, a dispatcher sounds a lot nicer than, say, an AbstractSingletonProxyFactoryBean).

And so it happens that, perhaps even unknowingly to you (you’re busy configuring a pool router), your actors start getting names such as:

  • Dispatcher
  • IncomingRouter
  • FailureSupervisor

I’ve observed this on three projects now, for two of which I delivered an introductory Akka training to the team beforehand. I’d say that this anti-pattern is especially to be found in projects where people are just getting started with Akka.

Now, why is this a problem?

I can think of a few reasons why this type of naming isn’t such a good idea:

  • when anyone with some Akka know-how will join the project, they’ll be quite confused. They’ll think that a Dispatcher is an Akka dispacher, where in fact it is a hand-crafted message router that should have been implemented as an Akka router
  • as you learn Akka, you and your teammates will also get confused - is this`IncomingRouter` really a router?
  • your actor hierarchy should aim at reflecting your business domain. That’s the beauty of actors, that they embody object-orientation done right (via message passing). The actor model and its implementation in Akka let you focus on what matters (actors and message passing) and you can even configure most of the deployment concerns only through the configuration (not through the code), making the code more readable by focusing on the business concerns. Interleaving this with actors named after technical concepts kind of ruins this very nice design possibility
  • finally, there’s a high chance that you will have unwillingly started to re-inventing the “Akka wheel” in some cases, re-inventing routers or the built-in supervision mechanism

In short, be careful about how you design your actor system and how you name your actors. This is, after all, one of the most important things in building actor systems (and, quite arguably, software in general).

Does your application show some of the symptoms described above? Contact me if you want a review of your Akka application.