Coming from a java background to rails I found it entirely refreshing that everything wasn't in a utility class or service. Decomposition of a system using utility classes and services(in the n-tier style) is to make your system more procedural rather than more OO. This article is encouraging more OO patterns, closer in spirit to DDD. The article doesn't actually go into this but all of the techniques described can be used to compose a class so that there is still a single API for each model in your system i.e. the decomposition into policies, decorators, services(of the domain type) etc. can be hidden from the user behind the model api.

That's a good point. It sounds like what you're describing is essentially a Facade. That can be useful if you need coordinated objects to manage complexity, but want to keep it simple for clients to use that part of the application. I sometimes create a Facade for a Ruby module that is a package of fine grained classes.

you shouldn't have so many if at all utility classes in java as well services should be used to compose process behavior not domain behavior IMHO service -> enroll user user -> domain behavior eg. concrete distinct action in responsibility of that domain object I hate when people write code like this get attributes of object do something with attributes set attributes back

instead having operation on object doing this and clearly encapsulate behavior and hopefully data as well