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.
Best Answer
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.