Sometimes I’ll start to code and I don’t even know where it’s going. I just hope I find it along the way (Yes, I love The Office. No, I'm not superstitious, but I am a little stitious).
Hey thanks for writing this. It reminds me about form objects and service objects (for when you are saving and retrieving respectively). It is pretty similar, but I like the name of "cases".
It is interesting to see how many devs are changing on Rails from the common pattern to use objects (following SOLID), Rails projects got success, the time goes by and the projects became hard to maintain so it was needed to go back to foundations. It is good, don't know if Rails 6 will introduce some guidance about these topics (I don't think so).
Hey thanks for writing this. It reminds me about form objects and service objects (for when you are saving and retrieving respectively). It is pretty similar, but I like the name of "cases".
It is interesting to see how many devs are changing on Rails from the common pattern to use objects (following SOLID), Rails projects got success, the time goes by and the projects became hard to maintain so it was needed to go back to foundations. It is good, don't know if Rails 6 will introduce some guidance about these topics (I don't think so).
Really glad that you liked it =)
Because there is no guidance/common way of writing business logic on rails, what I've seen so far is that each company does it in a different way.
Using use cases like I described in this blog post is one of them.
btw, I also recommend to check some design patterns in ruby: github.com/davidgf/design-patterns...
it's quite interesting =)