Junilu Lacar wrote:
Eric Graysman wrote:Yes the PricingService might be a God class, so im happy to hear other suggestions on how to design it
But its not really doing anything but orchestrating the flow of calls to other components. So it does not contain any other logic than that.
How would you design it?
Well, I'd start with names. If PricingService is, as you say, only orchestrating the flow of calls to other components, it sounds to me like it's a Controller of some sort. That's what controllers do. They know the flow and they know about dependencies between different parts of the system. So I'd separate the flow control logic out to a PricingRequestController or some similarly-named class. Then I'd write my first test.
Then I'd see if that test code told a good, sensible story. If not, then I'd look at a different design option and experiment with that.
Assuming I feel good so far, I'd write another test, to extend the story told by the tests so that we're testing the next step in the process flow. And so on and so forth, over and over again, experimenting, learning, evaluating options, then either continuing or pivoting to a different design option. All the while, I have tests that tell me everything I believe so far about the system and how it works is correct (assuming my tests are all passing).
Junilu Lacar wrote:That description just makes me think "God class" -- you're say "still inside PricingService.getPrice()" waay too much, even for things that really have to do with Customer, like customer validation.
The other thing that jumps out at me about your description is this: "How the hell are you going to test that?" and I'm guessing the answer is going to be something along the lines of "Well, it's complicated." The way you described it, you bet your bottom it's going to be complicated to test. I'm guessing that currently, any testing you're doing needs a full environment, maybe submitting requests through PostMan or a similar tool, looking at log files, and a whole lot of other tedious and time-consuming things. Is that a good ballpark estimate or did I hit it right on the money and out of the park?
Junilu Lacar wrote:
Eric Graysman wrote: ... But im not really liking this, because the Product and the PriceRequest are actually just immutable DTOs, and it dont feel right to but business logic into them.
Also it wouldnt feel natural to inject the necessary dependencies to external services into the Product.
Make sure you are clear on the difference between DTOs vs Domain Objects -- DTOs have their use but people often misuse them. I have a feeling you are misusing them. See https://martinfowler.com/bliki/LocalDTO.html