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.
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.
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.
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.
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)
I like such talks where the takeaways are simple and can be implemented in our day to day projects or job.
I did the same, I just called that stuff UseCases instead of Services. Same implementation! I feel a lot less lonely now, thank you!
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.
Phenomenal presentation. Thank you.
Such a great talk, and makes so much sense !
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.
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.
Amazing talk! Made me reflect a lot! Tks
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.
Great talk!
great talk, thanks a lot!
My favorite Not Uncle Bob
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)
Instructive and laughable talk :D