I'm working on refactoring a project. The business logic looks very much like using the Strategy pattern would be very beneficial, because depending on the values of three properties (let's say age, gender and salary), a different policy of discount and validation is applied.
My first idea was to put the logic responsible for deciding which policy to apply into a StrategyFactory, and have it return a different implementation of a Strategy interface. My concern is related to where to and where not to use DI. The StrategyFactory will need some DI to call other services, as will some, but not all of the strategy objects.
So in the end, I have to either annotate almost everything as a @Service/@Component or have the Factory send the services to the strategies via parameter, what looks even worse.
Am I missing something or is this normal? Could it be that the application layers are too tangled? Is this not the right case/way to use the strategy pattern?
I just need a brief answer to if there is anything that sounds very obviously wrong.