To add to the discussion
Having just app/models, app/controllers, app/views, app/helpers and lib is great. There are no app/models/services, app/models/entities, app/models/foos and in different projects and stages you can use different concepts. But we all know in our team that “business logic is in app/models”
But then there are concerns which “are just mixins added to autoload paths and some syntax sugar”. We’ve used concerns successfully when it comes to Picturable, Previewable, Permalinkable, but we’ve failed with others that should have been just POROs. - like we have a concern that is HasReputation, UserWithData.
The things I have experience to be difficult and I’ve been helping every member of our team with them and are not easily understood from documentation and guides are
- “What do you get by extending ActiveSupport::Concern?”
- “Why is there a different name in rails for a mixins?”
- “When are we using concerns”
It kind of feels they are central to rails as a new rails.project is created with two concerns folders, but it is not clear how central.
In addition to all the other good suggestions In the thread what I think would help many is a place pointing just that “concerns are just mixins with sugar syntax and you need it because…”