The Shape & the (Missing) Idea of Service Object

Key Ideas

1. Service objects are a de facto standard for organizing complexity in Rails apps, but there's no deep justification behind it.
2. The form of a service object itself doesn't provide value and can distract from proper code organization.
3. An important concept is dividing code by the type of work performed, rather than simply wrapping everything in service objects.
4. Code Topology Notation - a visual notation for discussing code structure.
5. Separating code by levels of abstraction into layers (models, mutators, services, controllers) is more effective than using service objects.
6. Service objects often mix different levels of abstraction in one place, which complicates the code.
7. The Fowler-Evans Ruler - a tool for evaluating the quality of service objects based on ideas from these authors' books.
8. It's important to distinguish between domain services and technical services, rather than lumping everything into a single "services" category.
9. Service objects can be used, but shouldn't be perceived as entities of the same level of abstraction.

Learn more by watching recording of my talk in Wroclaw