IOfferValueCalculator does not sit in the innermost layer of the Onion

It probably should - or at least be treated as such. If I understand correctly, the code is taken from a presentation where the speaker refactors a service-oriented anemic design into a rich domain model. There might still be traces of the old design in the "after" code. That there remains a separate Services layer post-refactoring might not be intentional.

should I be mocking IOfferValueCalculator (a Domain Service)?

• Some rare domain objects may be injected dependencies that talk to the outside world, i.e. cross architectural boundaries. This should probably be avoided, but if it cannot, this is when mocks are needed. In any case, you should mock the dependency, not the domain object.

• The rest of the time, even if in a Domain-ish layer next to Domain, I agree with the articles you cited that isolated domain tests have no need for mocks.

IOfferValueCalculator does not sit in the innermost layer of the Onion

It probably should - or at least be treated as such. If I understand correctly, the code is taken from a presentation where the speaker refactors a service-oriented anemic design into a rich domain model. There might still be traces of the old design in the "after" code. That there remains a separate Services layer post-refactoring might not be intentional.

should I be mocking IOfferValueCalculator (a Domain Service)?

• Some rare domain objects may be injected with dependencies that talk to the outside world, i.e. cross architectural boundaries. This should probably be avoided, but if it cannot, this is when mocks are needed. In any case, you should mock the dependency, not the domain object.

• The rest of the time, even if in a Domain-ish layer next to Domain, I agree with the articles you cited that isolated domain tests have no need for mocks.

IOfferValueCalculator does not sit in the innermost layer of the Onion

It probably should - or at least be treated as such. If I understand correctly, the code is taken from a presentation where the speaker refactors a service-oriented anemic design into a rich domain model. There might still be traces of the old design in the "after" code. That there remains a separate Services layer post-refactoring might not be intentional.

should I be mocking IOfferValueCalculator (a Domain Service)?

• Some rare domain objects may be injected dependencies that talk to the outside world, i.e. cross architectural boundaries. This should probably be avoided, but if it cannot, this is when mocks are needed. In any case, you should mock the dependency, not the domain object.

• The rest of the time, even if in the layer next to Domain, I agree with the articles you cited that isolated domain tests have no need for mocks.

IOfferValueCalculator does not sit in the innermost layer of the Onion

It probably should - or at least be treated as such. If I understand correctly, the code is taken from a presentation where the speaker refactors a service-oriented anemic design into a rich domain model. There might still be traces of the old design in the "after" code. That there remains a separate Services layer post-refactoring might not be intentional.

should I be mocking IOfferValueCalculator (a Domain Service)?

• Some rare domain objects may be injected dependencies that talk to the outside world, i.e. cross architectural boundaries. This should probably be avoided, but if it cannot, this is when mocks are needed. In any case, you should mock the dependency, not the domain object.

• The rest of the time, even if in a Domain-ish layer next to Domain, I agree with the articles you cited that isolated domain tests have no need for mocks.