Better organising our code

[peteryates]

Currently across both ECF and NPQ we have business logic spread far and wide.

Path	Responsibilities
app/models	database interaction, business logic
app/services	business logic
app/helpers	display logic, business logic
app/controllers	dealing with requests, business logic
app/views	displaying data, business logic
app/components	displaying data, business logic

The mixing of business logic with things that already have responsibilities of their own make things hard to test and often result in us having to create loads of records in order to get the application into a particular state.

Proposal

We move the business logic away from models, controllers, helpers and views, where it's difficult to test, and into services and components, where it's easy.

Then we have something more like this:

Path	Responsibilities
app/models	database interaction (validation, scopes, relationships)
app/services	business logic
app/helpers	display logic
app/controllers	dealing with requests
app/views	displaying data
app/components	displaying data, business logic

Now, each of the Rails-provided parts of the app do only what they're intended. This makes them easy to test. We make sure a controller is doing the right thing by making a request and ensuring the service object it calls receives the right params. That's it.

Our business logic is now in two places, services and components. Neither of these rely on anything else (database, HTTP requests, etc) and are easy to test because we can pass into them the objects they need, and interrogate them directly in the specs.

This reduces the need for elaborate factories, creating loads of interrelated objects, etc. It also reduces the impact of the same functionality being tested in multiple places because the tests overlap.

More info

This talk by Dave Copeland from RailsConf 2022 makes a strong case for this kind of approach.