alejandrobabio / music-api

0 stars 1 forks source link

user_cases folder #2

Open alex-nexus opened 6 years ago

alex-nexus commented 6 years ago

I see you add all the logic into this user_cases folder. Can you elaborate why and how you designed it?

alejandrobabio commented 6 years ago

It represents the business rules, at this moment they are so simple that they could almost be inside the Grape::API (or the controllers in Rails). Much has been written about simplifying controllers through the use of services. In this case, I have gone a step further and I have defined it as a standard in the application. Why? for those who read the code for the first time, once they find this folder, where their methods are defined as "action" + "subject" right away, you can figure out the content of each file. And inside then, are the rules that govern that use case. It should be independent of the rest of the application and calls the data update interface (right now AR models). How? The idea is taken from the Uncle Bob Architecture conference in 2011. He comments that looking at the directories of a Rails app, you can't say where the business rules are, and mentions "use cases" as a name for the folder that holds them. I have also decided to follow the "Tell don't Ask" rule: once a "use case" is called via "call" it returns the required result or raise an exception. There is no other possibility, the "attr_reader"s are private and they do not have "attr_writer"s. The class is not frozen (yet), but it should be so that the mutation of objects is avoided. All this reduces the chances of errors.