refactoring a bloated service class

Say we have in the domain / service layer a class that handles various scenarios. This is something ive just encountered and it badly needs refactoring.

By various scenarios, i mean that there are lots of case statements to handle what is passed into the service.

for example think of a car api where it handles different types of models ford, toyota etc. lets pretend this service handles car maintenance based on type of car and thats the role of the service, call it CarMaintenanceService. there is a bunch of case statements in this service to handle each type of car and how it should be serviced, specific parts to check, different components to order if required. Given the large amount of case statements the factory pattern comes to mind.

Lets call the factory CarMaintenanceFactory, it provides a concrete implementation of of the maintenance required for that model. however the business logic for this is quite large.

Is it better to create a factory within the domain / service layer that handles this complexity or is there a time where a new project is required that does the leg work; and if so, how does it fit in with good architecture practices?

Most apis suffice with a 3 layered project structure controller -> service / domain -> repository. However with a very complex domain layer, it can lead to a lot of code in that layer. so im looking for good resources on how to address this problem. What happens when your domain / service project gets too bloated with code? how do you split it out?


How do you refactor an API when your service layer in a 3 project solution gets too bloated. i.e. the the layers are the 1) controllers 2) service / domain 3) repository. if there is a 4th layer to address code bloat problems in the service layer, how do you approach addressing it?

submitted by /u/Neophyte-
[link] [comments]

Leave a Reply