Tired of writing messy messy "if" statements for all your exception handling? Learn how to take full advantage of functional programming theory, without the theory, Ruby-style!
https://github.com/mindeavor/solid_use_case
5. A Service is an object
that represents a process.
6. A process is something you do.
• Typically initiated by the user
• Usually implemented as a dedicated class
• Named with verbs, not nouns
• Examples: SignupUser, PurchaseItem, etc.
SERVICES
10. Why a Service useful?
• It encapsulates domain logic
• It thins out your models & controllers
• It ties together cross-cutting concerns
• It makes your Rails app easier to test.
SERVICES
11. A service layer is about clear separation.
• Rails depends on the service layer
• The service layer knows nothing about Rails
(routes, controllers, & views)
• Other things could depend on the service layer
(REST API, web sockets, rake tasks, etc.)
• ActiveRecord is unavoidable, however.
SERVICES
13. Quick Recap
• A service is an object that represents a process
• Services encapsulate domain logic for specific
processes
• No functional programming (yet).
SERVICES
15. Services: Another Perspective
A service is a sequence of steps
• They often involve a lot of setup
• Authentication, authorization, validation, etc.
Any one of these steps could fail
• How to handle failure??
RAILWAY
37. Quick Recap
• Split steps into methods
• Return a success or failure in each one
• Elegant (with gem) error handling!
• Steps can be tested independently
RAILWAY
48. Recap
• We can compose services like we can steps
(in fact we can compose anything that returns our success or failure)
• Functional programming rocks!
COMPOSE
49. Conclusion
• Service layers are great for apps more complex
than CRUD
• Railway oriented programming is great for
seamless error handling
• Functional programming gives us composable
services!