Missing Guide to Service Objects in Rails - Riaz Virani

[@rockatanescu]

I've used service objects multiple times and I've always felt like something was off. After reading about DDD I think I finally understood what I don't like about them: service objects allow a high degree of complexity and most of the times you do not need or want that much complexity because it makes testing and refactoring a lot harder. One clear sign of the underlying complexity is the need to talk about control flow and how using the Ruby version of the GOTO instruction is a "preferred approach". As an experiment, I've tried understanding a bit better the behavior and how the objects interact and I've noticed that almost always a plain Ruby object was more than enough. Of course, service objects have their uses and it's an excellent idea to talk about them. However, I've seen many times people reach for service objects first, allowing a lot of complexity to creep in.

[@darkamenosa03]

The very hard to read at 21:22 is actually the easiest to read. We dont need to spend time to understand the pattern and anyone can understand. Pattern was born to solve problem, not to create problem. Adding a new dependency (gem) just to achieve a little beautiful code is not what I want to do. Since no one know what would happen tmr for that dependency. I trained my whole team from OOP to FP(functional programming), and switched to write code like that. It ends up a mess. When new member entered the project, they had hard time just to grab the concept. The first service object pattern is more elegant than the second, since many developers are more familiar with OOP, and you dont have to add extra dependency to the project.

[@hackur]

Extremely informative. Exactly what I came for. I'm glad he covered all the different approaches w/ pros and cons.

[@BillyYarosh]

I’m glad others are thinking about service objects. Most other language frameworks use service classes that contain all CRUD actions. I find it interesting that ruby folks still think of services in the context of a single action. So OrderService instead of OrderCreator.

[@ricardororiz1728]

Thank you so much! This is a problem that a tackled with so many different solutions - and this video kind says "It's Ok, a lot of people have this problem and these are some solutions"

[@vendetta3953]

masterpiece! Talked about almost every nuance one might face! Thanks very much

[@haroldpepete]

great guide, thanks, you have a new subscriber

[@AndyKoch]

Really excellent presentation!

[@benjaminmoseslieb9856]

Great talk. Good description of the problem domain and various ways to approach dealing with it. Was interested in the "functional" approach, but (and this is probably because I don't do a lot of functional programming) I couldn't tell what was specifically functional about it (I was thinking mutability etc). Will look at lighthouse. Wonder if there are any other gems for service objects that are basically POROs, where you don't have to invent the return classes yourself etc.

[@edimossilva]

Amazing talk!

[@EnjoytheMents]

Great video. Really helpfull!

[@Igoryan481]

Thank you!

[@prakashsanyasi5608]

I loved it 🥰