The service object discussion in Rails is somewhat interesting. Sometimes I get the sense that we’re trying to push for easy decisions and avoid one of the bigger problems in programming: naming things. Part of the issue is that our definition of service isn’t really specific. Is it basically moving all the logic that was in our models to something else as a solution to having fat models?

From what I understand, in the original DDD definition of services, they’re light classes that help decouple objects. For example, we might have an order that needs to be able to associate with products. We don’t really want order to call product methods directly and vice versa. Given those restrictions, how do we pass products to the order? This is when a service makes sense. The service can grab the products based on some condition and pass it to the order. The heavy lifting, such as the logic to get the products and the actual adding of products to the order, happens in their respective domains and not the service.

Re-visiting fat models, the solution is to come up with different objects that models what your code is doing and not just throw everything into nameless service objects.