Let's say that I have a service for Job Offer entity in CRM app. Job offer is related to many many things, so there will be lot of methods on service layer to interact with above.

What should be considered better approach - one big, fat service class for whole Job Offer family (like, 50 methods in service), or breaking it into few smaller services targeted for specific parts of interactions (one for saving/updating basic data, one for handling job offer details, one for job applications etc).

Pros of one fat class that I see is that it could be more DRY than multiple smaller services. Of course one can always can call another service from other service, but this will cause less modularity. Cons - I'm afraid that large service class will be harder to maintain and to test.

  • 1
    "Job offer is related to many many things" Maybe there should be different types of Job Offers. Or maybe the Job Offer can be divided into different components. And why do you have service class, when methods related to JobOffer entity should be inside JobOffer class?
    – Euphoric
    Jan 9, 2015 at 9:09
  • I'm talking about methods like "saveOffer", "deleteOffer", "activateOffer", "markAllApplicationsAs", "getOfferApplications" and so on. I thought that those methods should belong to service layer.
    – ex3v
    Jan 9, 2015 at 10:06
  • You can consider it all part of "Job Offer" business logic and still break it into smaller components. Pertaining to the same part of the program doesn't necessarily mean you can't separate it into read operations, update operations, insert operations, etc.
    – Neil
    Jan 9, 2015 at 11:08
  • What's a job offer in a CRM app?
    – Jimmy T.
    Feb 20, 2017 at 12:43

2 Answers 2


The other end of the spectrum from the fat service class is the use of commands and a command processor. Basically each of your service methods is broken off into its own command.

This article by Ian Cooper gives a good description of refactoring from a fat service to commands:

Some of the pros of this are razor-focused single-responsibility of your classes, and the improved testability that that brings. Some cons - you have now introduced an extra level of indirection that isn't always easy to make sense of, and you get a bit of a class explosion.


Well, I'm typically against anything fat in the application unless there is no way to avoid it. So, I say: break it apart.

Reading through your comment I can suggest some ideas:

I'm talking about methods like

  • "saveOffer", "deleteOffer", "activateOffer" - OfferService definitely.
  • "markAllApplicationsAs" - not so sure about this one. Probably just belongs to OfferApplicationService with just offerId passed as a filter
  • "getOfferApplications" - OfferApplicationService with offerId passed as a filter I say.

and so on. I thought that those methods should belong to service layer.

Sure, they should.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.