Let's say we have business logic to perform in an MVC framework after a user submits a form:
class BusinessLogic: def sendDataTo3rdPartyApi(self): # do stuff def validateResponse(self): # do stuff def persistData(self): # do stuff def calculateFees(self): # do stuff def sendDataToAnotherApi(self): # do stuff
POST form data is received by the controller and it passes that data to the business logic layer for processing. All of these functions are necessary to process the data. We recognize that this BusinessLogic class is likely doing to many things, so we abstract the various methods into their own classes and inject them via DI:
class BusinessLogic: def __init__(self, dataSender, validator, dataPersister, feeCalculator, anotherDataSender): # assign objects to private properties within class def doLogic(self): # utilize the injected classes to perform necessary business logic
The problem I see with this approach is that abstracting the functions into classes that perform one thing still leaves us with a class that does too many things--it's just in the form of classes instead of functions. We can try to move these classes out of this class, but we would just be sending the dependencies up into the controller. As our business logic gets more complex, the more we're going to have to inject since we're creating a class for each particular business requirement.
I feel like no matter what you do, you'll always require a god class of some sort to organize the different parts together for execution. Now I'm unsure if this is necessarily a bad thing, but I'm wondering if there is a better approach to refactoring a business logic class like this.