Service layer - fat service classes?

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.