RailsConf 2022 - Your Service Layer Needn't be Fancy, It Just Needs to Exist by David Copeland

Where would you put your business logic if not in Active Records? The answer is a service layer. Your service layer provides a seam between your user interface and your database that contains all the code that makes your app your app. This single design decision will buoy your app's sustainability for years. You'll learn why this is and how to start a service layer today without any patterns, principles, or fancy libraries.
_____________________________________________________________
Cloud 66 - Deploy your Rails code directly from your repo to any cloud in minutes. Cloud 66 offers the convenience of Heroku, but on any cloud and in any region, with persistent storage, custom network configuration, zero downtime deployments, blue/green and canary releases, WAF, and more.
Get $100 Cloud 66 Free Credits with the code: RailsConf2022
($100 Cloud 66 Free Credits, for the new user only, valid till 31st December 2022)
Cloud 66: cloud66.com/fr...

[@ashishrao3069]

I like such talks where the takeaways are simple and can be implemented in our day to day projects or job.

[@Ashton351]

Phenomenal presentation. Thank you.

[@burattinodilegno]

I did the same, I just called that stuff UseCases instead of Services. Same implementation! I feel a lot less lonely now, thank you!

[@xzdasx]

I am using a similar approach, but sightly different. UseCase is more about what we can do, Services is how can I do it.
A service is just an action, when UseCase is a collection of actions.

[@yolo_bento]

Such a great talk, and makes so much sense !

[@ppercipio]

I find the approach taken in by Makandra in the Growing Rails book more preferable.They create use-case specific subclasses of the primary model like `User::AsSignup` and put this once-off logic within those classes. When used with `active_type` then view rendering and url helpers continue to work as normal with these subclasses and your validations still work fine with forms. Oh yeah and you can add single-purpose fields to these models too.

[@augustsbautra]

Interesting approach, a sort of hybrid of Form object and Operation. I find the strong argument against complex business logic in models is lack of isolation - can get hard to see what instance methods are used, doing extract-method refactoring will only spread the definition out etc. Having that one class for that one business operation just takes the edge off.

[@repoles]

Amazing talk! Made me reflect a lot! Tks

[@SergeyCoder]

I think people hate service objects cause they can't properly cook them. Service object it's same as PORO but used not as public method of some class, it used as separated class with one entrypoint for some logic (call/perform/execute method) & isolated state. When you use much PORO (as we, in our project), you will have bunch of entrypoints in your classes. And having code increasing in size, you understand that your PORO class use huge isolated state & share this state between different entrypoints, producing complex non-testable edge cases. What you should do? Yes! Separate class into several classes! Called what? Yes! Service objects! :) And you will understand that having isolated, testable, small classes: EmailNotifier, SmsNotifier & ViberNotifier is much better than Notifier#send_email, Notifier#send_sms, Notifier#send_viber. Yes, service object can be dependent to other service objects, it's ok. As example, UserCreate service object can call AccountCreate & EmailNotifier service object.

[@mykhailomaidanskyi2085]

Great talk!

[@vitaliiyanishevskyi6804]

great talk, thanks a lot!

[@RichOrElse]

My favorite Not Uncle Bob

[@fuu812]

We found a good approach is to place for each class just one `call` method:
- for smaller repo eg. `app/services/invoice_service/create_invoice.rb` (monolith)
- for medium repo eg. `components/finance/invoice_service/create_invoice.rb` (modulith)

[@szymonsoczewka7893]

Instructive and laughable talk :D