"A great solution is to put it into lib/checkout.rb and write a custom Checkout class that manages how Customers and Carts interact." That is significantly dif

"A great solution is to put it into lib/checkout.rb and write a custom Checkout class that manages how Customers and Carts interact." That is significantly different than implementing a service layer, which "defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation." In your typical ServiceLayer style app, most of the calls are just direct passthroughs to the domain model. Frankly, the controller layer is a sufficient service layer for many complex applications, as it handles different clients and request types. There is often foolishness in putting too much of that logic in a single controller method, but it is wrong to suggest that adding the overhead of the service layer pattern in place of referencing the domain model from the controller fixes this (putting it in lib certainly makes a bit more sense). The example given in the article is a bit of a horror show. It's probably not a service layer. I am sure a bit is left out, but it's going to convoluted lengths to avoid putting anything in the domain model. Dynamically extending individual instances of employee to add a pay_date method? Creating a new instance of the service on each request- when it could be done with static methods? Sadly, it doesn't make sense to model your whole domain twice. Let's see what the employee service used to list, add, update, and remove employees is like. Any real system is going to end up with a domain model object to represent a payroll, which is where this logic could go. The root problem is Uncle Bob just doesn't like the ActiveRecord pattern- in which case just use a different ORM.