One Service Class Per Business Object - Not as Bad as You Think . . .

The thing I like about object oriented modeling is that it provides quite an elegant approach to solving lots of problems. No questions it has weaknesses. State tends to cause all kind of problems for handling concurrency issues, and without adding Aspect Oriented Programming concepts, cross cutting concerns like logging and security don't usually fit well into an object model, but on the whole I really find an OO modeling approach to be a great way to develop apps.

Given that, I find that within my model, I really like to describe everything in terms of business objects. I put instance specific logic (validation, smart getters and setters and - via composition, persistence) in my business objects and what in other languages might be treated as class methods (such as for returning collections of instances) in my service classes. All of my service classes extend a BaseService class which automagically takes care of implementing methods like new(), getByFilter(), getByProperty(), deleteByProperty(), deleteByFilter(), save(), insert() and update(). Because of this simple design decision, I can describe the vast majority of my methods as parameterized calls to these base methods using a little XML, and I can generate/dynamically interpret those DSLs so I can implement the vast majority of my model methods without actually having to write and debug code. I've built a lot of applications this way over the last couple of years, and honestly, it's working out great. I just handle inter-related objects using my Data Mapper which allows (for instance) a Category to include subcategories and products within the category, and I find that I have to write very little code to implement most of my models.

The question then is what is the benefit of NOT having one service class per business object? It seems to me that it adds another layer of complexity to an application (as now you need to understand both the service layer and the underlying model) and just requires more thinking, coding and effort to create a working object model than a pure business object approach.

I understand that in general the idea of a Service layer is a facade that simplifies the object model to provide a custom API for controllers and that handles orchestration between business objects. However, in my experience, many such problems can be solved by allowing your business objects to interact via their relationships and occasionally by adding a new business object for describing interrelated objects.

I'm definitely open to the possibility that I just haven't come across use cases that require a separate Service layer that is independent from the business objects (the apps I build are definitely not trivial - but they aren't that complex either), but I'd be interested to hear of some situations where a service layer genuinely adds enough value to an application to justify the extra time it takes to design and code it. I also think that for many of the apps people are building, they could do much worse than starting out with treating the "service layer" as a place for class methods in ColdFusion until they come across a specific problem that requires the extra complexity of a true service layer.

Thoughts?