I will bring here an approachable solution for building rails applications using some fundamentals of the so-called clean architecture. But, what is it?
It's hard to tell what it is without telling about the problem.
The problem is, look at your rails application, try to identify what it does, open your app folder and try to identify again.
We can see some folders like controllers, models, helpers and so on. Even when opening one of those folders we cannot say what is does, but we can only say what that application have, like users or products. The clean architecture came to try to solve this problem.
One thing we can notice on that rails applications is that it's screaming web framework!.
But one thing we can never forget is that the web is a delivery system and should not dominate our code.
As you can see, the framework is just a detail in that architecture, it's a delivery mechanism. The interface to the user can be a website as well as a command line tool, the business rules go on the use cases which can interact with entities.
The MVC pattern was created by Trygve Reenskaug to use with SmallTalk for graphical user interface (GUI) software design in 1979.
But what happens when we use this approach to build our entire web application?
I'm not saying the MVC is bad, I'm saying that it's part of the delivery mechanism not of the application architecture.
Imagine you have a web application and you send invoices to your users, and then they pay their invoices. So that use case could be named 'pay_invoice' and to group related classes I will create a module call Accoutant.
when to write use cases?
When you only need to manage resources, you can and should use the rails way which is resource oriented so it makes sense, but when you have a special logic and it's very unique to your business rules, you write use cases like the code above.
After all that work we can look on our application and quickly see what it does instead of just seeing resources which is what it has, you can also move between frameworks or create new interfaces to use your unique business rules.
Keep in mind that there is no silver bullet in programming, but this is for sure a very effective approuch to keep your use cases organized and keep your software architecture clean.