I have an application that I\'m trying to build with at least a nominally DDD-type domain model, and am struggling with a certain piece.
My entity has some business logi
Given what we've seen of the classes, I don't think they're really services in the blue book sense, and I would keep the calculators in Ticket
.
Neither FinancialCalculatorService
or RateCalculationService
has dependencies on domain entities - they both operate on primitive values. Applications shouldn't have to worry about how to calculate the financial gain that would result from a ticket, so it's valuable to encapsulate that information inside the ticket itself.
If they really don't have dependencies on domain entities, consider thinking of them as 'standalone classes' rather than 'services' (once again, in blue book terminology). It's certainly appropriate for Ticket
depend on strategy objects (FinancialCalculator
and RateCalculator
) that do not themselves have exotic dependencies and do not themselves modify the state of domain entities.
Update for Edit 2. I think one of the advantages of making the calculators separate classes is that you can test them independently of Ticket
. Strictly speaking, tickets aren't responsible for performing those calculations, they're responsible for making the right calls to those collaborating classes. So I'd be inclined to make them inject-able / mock-able as they were in your initial example.