[tinco]

This is due to a conflict of philosophies within the RoR community. Basically the clean code enthusiasts (which are also more likely to subscribe to DDD) argue that business logic should not be tied to which specific web application framework you use. So it should basically be in a separate codebase, either in the `lib/` directory or literally in a different project and included into your application as a Gem.

This makes sense from an objective perspective on what constitutes clean code, and I used to believe that this is what a really large enterprise Rails codebase should be refactored to eventually (although I never personally did so).

Rails offers an alternative approach to this however, that is less neat from an objective perspective, but actually follows the Rails principles a lot better and it's called Rails engines. Basically you split your Rails app up into multiple mini-rails apps for each domain called Rails engines, each has the same directory structure as a Rails app and you get the full benefits of a regular Rails app inside each. I used to think this was an ugly approach and I never even considered it, but now after over a decade of Rails development I've made a 180 and I believe this is the way to go.

The "clean" way forces you to construct interfaces between your business logic and the Rails app, basically introducing a lot of extra boiler plate. All for the perceived benefit of making your business logic be abstract of the Rails framework. This violates YAGNI of course, and by a huge margin too. I've never seen the business logic of a Rails app be ported to some other framework in 15 years, the most I've seen is reusing code in a Grape API that was mounted inside the Rails app. And what you give up is Rails' convention over configuration and its predictable structure, and the general documentation and knowledge of that structure that people can carry from job to job.

[drekipus]

I'm struggling / thinking about this myself a lot.

I've learnt a bit of Django's app-centric model (which is similar to rail's "engines")

I work for a company that enforced the data/domain/interface with a plug-in approach to custom code.. and I liked it.

But for my own projects, I get stuck choosing between the two, I see more benefits in the layered approach, but I feel like I'm fighting the tide with every project I start

[kennethwolters]

That's very interesting! In Django this "Rails Engines" approach is the default. A Django project will be made out of multiple Django "apps", each having its own routers (called URL-dispatchers), controllers (called views - yes, I know its weird to call them that), models and templates.