It will never not bother me that Rails, and many frameworks inspired by it, encourage grouping modules/classes together in a folder based on the design pattern puzzle piece that they represent, instead of organizing the modules related to a slice of an application’s domain together.
All of this fuss about what to name common abstraction(s) for interactions stems in no small part from Rails’ suggested directory structure. It encourages developers to think of what term(s) are worthy of being peers with “models” and “controllers”, when that’s really an orthogonal concern to their application’s domain.
I make this complaint with confidence, having shipped dozens of rails projects and still working with (or around) it every day.
But Rails does have this capability, with Engines. If you build a feature as an Engine, it’s actually quite close to the abstraction necessary for a logically distinct microservice. https://guides.rubyonrails.org/engines.html
And if you want to go fully decoupled you can use trailblazer. It still uses MVC concepts but is more like a widgets framework, so you can create decoupled partial models and views and re-use them across different parts of the application.
Rails use at large seems to have converged on the “use-case controller” with “row-table as object” (row-table gateway) patterns, rather than the Active Record pattern. Procedural scripts and sub-procedures driving database data.
This is in common with most web development these days which eschews an independent object domain model.
How to represent behavior and constraints outside of the static relational database model without it approaching a big ball of mud, as size and domain complexity increases, is the question. Rails just makes this more apparent, because its effectiveness lets one think more about the domain problem than most.
It will never not bother me that Rails, and many frameworks inspired by it, encourage grouping modules/classes together in a folder based on the design pattern puzzle piece that they represent, instead of organizing the modules related to a slice of an application’s domain together.
All of this fuss about what to name common abstraction(s) for interactions stems in no small part from Rails’ suggested directory structure. It encourages developers to think of what term(s) are worthy of being peers with “models” and “controllers”, when that’s really an orthogonal concern to their application’s domain.
I make this complaint with confidence, having shipped dozens of rails projects and still working with (or around) it every day.
But Rails does have this capability, with Engines. If you build a feature as an Engine, it’s actually quite close to the abstraction necessary for a logically distinct microservice. https://guides.rubyonrails.org/engines.html
Having actually gone down this path, you do not actually want to use Engines as a module abstraction. The boilerplate cost is way too high.
Hanami Slices are an implementation of this that is actually good.
And if you want to go fully decoupled you can use trailblazer. It still uses MVC concepts but is more like a widgets framework, so you can create decoupled partial models and views and re-use them across different parts of the application.
Rails use at large seems to have converged on the “use-case controller” with “row-table as object” (row-table gateway) patterns, rather than the Active Record pattern. Procedural scripts and sub-procedures driving database data.
This is in common with most web development these days which eschews an independent object domain model.
How to represent behavior and constraints outside of the static relational database model without it approaching a big ball of mud, as size and domain complexity increases, is the question. Rails just makes this more apparent, because its effectiveness lets one think more about the domain problem than most.