Splitting up services -> Business Objects?

Question

I believe I structure my projects like many people do. You have a data layer (DAO's), service layer (services) and presentation layer (Spring MVC, Wicket, ...).

Usually a service starts of being quite simple and 'short'. Gradually however the service must support more and more use cases until after a while it becomes one huge class with many lines and methods and difficult to read and maintain. At that time you can either decide to stick with it or start refactoring which is a cumbersome and 'dangerous' job that can take a lot of work.

I am looking for a solution in how to prevent the need for any future refactoring.
One approach could be splitting up your services in several sub-services and make your original service a service façade. So, for instance, instead of a big UserService you could have a UserServiceFacade which delegates the calls to PasswordService, RegistrationService, ... .

It's not a bad solution I think but I'm not too enthusiastic about it because:

1. difficult to define in advance in which subservices to split the work; if you missjudged, you might still need te refactor aftwards or have a Service with only one method for instance
2. reuse of Business Logic can be more difficult if for instance PasswordService and RegistrationService require common functionality

Another solution might be using Business Objects which (in my understanding) can also be seen a subservices but then one per specific UseCase, so you might have BO's like CreateUserBO, CheckPasswordBO, DeleteUserBO, ... .

I'm a bit more enthusiastic about this approach because, in my opnion, it offers quite some advantages:

1. the BO itself is very readable and only does with it's contract requires it to do; all the rest can be delegated to other BO's, a single BO will be short and to the point
2. Easy to reuse functionality
3. Easier to change/switch the implementation of a certain UseCase: just inject another implementation with Spring
4. Easier to test: only need to test to specific UseCase, delegations to other BO's can be mocked
5. Collaboration: less conflicts if several developers work on different BO's then when they work on the same service

I do however also see some possible downsides:

1. a bit extra work (in the sort term at least)
2. Much more classes which could decrease the readability of your project?
3. one more abstraction layer: an extra step is required to find the actual implementation of a UseCase

The question or rather questions (sorry) are:

1. Are Business Objects the ideal solution for this problem?
2. Do you agree with the advantages/disadvantages of BO's that I list above and/or do you see other?
3. Are there other (good) solutions to prevent mega services ruining your day?

Answer 1

I would recommend you to look at this article on Domain Driven Design if your application is anything serious than college assignment. The basic premise is structure everything around your entities and have a strong domain model. Differentiate between services that provide infrastructure related things (like sending email, persisting data) and services that actually do things that are your core business requirments.

I would also suggest to explore Spring Roo - which brings in some revolutionary stuff in as far as strcuturing your layers are concerned like not having to need DAO layers etc.

Hope that helps.