The Ruby Unbundled Series: Designing and Launching New Features in Rails

Designing and Launching New Features in Rails

There is only one reason we design software

Let’s start with the meta question: Why do we bother with software design at all ?

Best practices may not be the best for your situation

When you search for Rails anti-patterns and best practices, you will find statements such as, don’t put too much logic in the controllers/models/views/etc. These are less so best practices as they are notional concepts to be applied in the context of your application and its features. There are no absolutes. Two hundred lines of code in one model class may be too much for a given feature, while it’s not enough for another. We want to push logic down to the lowest level possible, but in homage to Einstein, no farther. More on this concept later.

Push logic down to the lowest level possible

From a practical perspective then, how do you make design decisions? Where does the “business logic” belong in Rails?

Ruby on rails
Ruby on rails
  1. How likely is the concern to change or have variations

Putting these concepts into practice

Consider a banking application as an example. I know its a tired example, but bear with me as it is readily understood by almost all readers. We will briefly discuss three use cases:

  • Transfers
  • The addition of fees charged on transfers

Where should I put this logic? Oh yes, in the helpers.

But here we hit a decision point in Rails, as there is no prescribed directory for “service classes”. While Rails is highly opinionated on web application specific topics (i.e. Controllers in this case), it doesn’t prescribe where these “business logic” classes belong. Oh wait, I used a term there I’m not supposed to, but you know what I mean.

  1. Calculate the fee amount
  2. Modify the validation logic to verify the balance is at least the transfer amount plus fee amount (unless you are going to bill them later)
  3. Add bookkeeping for the fees, to ensure they are both deducted and credited to the bank

Microservices are more than just a buzzword

Many design decisions will look similar to this one, and it’s not by accident. This is why service-oriented architecture and microservices are pervasive trends. In fact, a microservice (which could be a REST endpoint or logically speaking simply a delegate Ruby class ) that handles fees should likely be a part of the design as well. Then the service change is to a) calculate the fee amount and b) invoke the fee service with that amount.

An integrated tool of software development tools to deliver higher productivity and better-quality software.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store