2.5.19 Extract domain logic from controllers, models and validators

The Garden Party application is following the MVC pattern and the underlaying “Rails Way” offered by the Rails framework.

This is considered good practice as this came with a standard set of conventions that each Rails developer knows, but it can be difficult to scale once the codebase reach a certain size. In most cases, the application models came to carry most of the domain logic, and relies heavily on callbacks and validations to control the data flow.

With time, these models start to grow longer and harder to read. Their behaviour becomes harder to test and can lead to unexpected errors and cause chain reactions.

Concurrently, controllers may become heavier as they are riddled with more and more domain actions or external services code.

One way to overcome such situation is to extract the domain (or business) logic outside of the application logic, leaving the controller to handle the requests and the models to persist the data. Recommendation:

There is multiple way to decouple the application logic from the domain logic. Each project and developer may favour one or the other depending on their preferences and requirements.

Here are some well-known methodologies:

• Domain Driven Design, a design approach. Arkency’s book on the matter.
• Hexagonal Architecture, a design pattern, sometimes used alongside DDD. An article about it.
• Trailblazer by Nick Sutterer, a gem, a book and a methodology. It’s main website.
• Rails-oriented patterns by Selleo, a set of patterns from multiple philosophies. The pattern gem, regrouping them all.
• Service Objects, a common love-or-hate pattern in the Rails world, usually targeted to fat controllers. An article about them from Toptal.

This recommendation is more a rework of the codebase and can't be treated as a single issue. Discussions on the matter is welcome, and if you're interested into working on this, come on the Matrix chatroom!