rails-contexts

Business logic in a Rails application should be placed in the component that matches its concern, such as a service object, policy, form, or query. Mapping logic to its ideal location keeps controllers thin and prevents hidden side-effects.

To decide between a service object or a policy, evaluate if the logic handles authorization or execution. Policies manage explicit authorization rules, while service objects encapsulate complex business operations like payment processing workflows.

Keeping Rails controllers thin requires enforcing Iron Laws that avoid side-effecting callbacks and make authorization explicit. Move complex operations to dedicated service objects, forms, or queries to suggest proper placement without modifying code.

Yes, this approach works with Grape API endpoints by mapping their business logic to ideal locations within typical web and API projects. It provides guidance on whether logic belongs in Grape endpoints, serializers, or underlying service objects.

Serializers should be used in a Rails API architecture when you need to format complex model data for API responses. They act as the ideal location for presentation logic, separating it from controllers and underlying business operations.