Business Logic Code Must Reveal Behavior

Overview

At the start of the course, we outlined a core part of sustainable Rails architecture, which is to not put business logic in the Active Records. It threw light on details about how to structure the classes that do contain business logic and that’s what we’ll discuss here.

As mentioned earlier, the key thing to do is isolate our business logic from our Active Records and other Rails-managed classes. How our business logic is structured is less important, but it’s not unimportant.

The way to think about it is that the API of our business logic class is as a seam. On one side of this seam is code managed by Rails inside a controller, job, or rake task. On the other side is logic specific to our domain and a particular use case that might use Rails but isn’t managed by it (see the figure below). This chapter is about how we define that seam.