Explicitly-Named Classes with Explicitly-Named Methods

When implementing the business logic, there are a lot of design decisions that need to be made. The architecture of our app serves to tell us how to make some of those decisions. Not putting our business logic in an Active Record is a start. We can eliminate even more design decisions by creating conventions around this seam between our logic and the Rails-managed outside world.

What is the simplest thing we can do (besides putting our code directly in Object)? If we had no Rails, no framework, and no libraries, we’d need to make a class with a method on it and call that method. Suppose this is our strategy for business logic. Suppose we always put new code in a new class and/or a new method. This would eliminate a lot of design decisions.

It turns out this strategy has further advantages beyond eliminating design decisions. First, it doesn’t require changing any existing code, which reduces the chances of us breaking something. Second, it provides a ton of flexibility to respond to change in the future. It’s much easier to combine disparate bits of code that turn out to be related than it is to excise unrelated code inside a large, rich class.

Classes like this are often called services, and we encourage the use of this term. It’s specific enough to avoid conflating with models, databases, data structures, controllers, or mailers but general enough to allow the code ...