In a way a lot of parts in Trailblazer are just that: "simple Ruby objects to break up logic and separate out logic". Not just from models but in the views, controllers and other places too.
Lots of Rails devs go through a process like the following:
* I want to introduce a Subscription, but that is not something stored in the database, rather it creates an Order, Invoice, Account and assigns products to them. Let me create a simple PORO for that.
* Now, where to stick that? Models? For now, that will do.
* I want to introduce a Trial, which is rougly similar to the Subscription just with different parameters.
* I want to introduce an Upgrade, wich can turn a Trial into a Subscription.
... and so on.
Quickly turning your "simple Ruby objects" into an even larger mess then the mess they try to solve. So you'll be adding abastractions, giving them names and common places in your app. And there: you've just built a part of a framework like Trailblazer.
Lots of Rails devs go through a process like the following:
* I want to introduce a Subscription, but that is not something stored in the database, rather it creates an Order, Invoice, Account and assigns products to them. Let me create a simple PORO for that.
* Now, where to stick that? Models? For now, that will do.
* I want to introduce a Trial, which is rougly similar to the Subscription just with different parameters.
* I want to introduce an Upgrade, wich can turn a Trial into a Subscription.
... and so on.
Quickly turning your "simple Ruby objects" into an even larger mess then the mess they try to solve. So you'll be adding abastractions, giving them names and common places in your app. And there: you've just built a part of a framework like Trailblazer.