I am trying to refactor a large and complex application to use DDD principles as and when I get time.
I have a class, which is completely isolated from the domain (it is only used by an application service) but part of the ubiquitous language. It looks like this (an old version of it):
public class CurrencyCalculator
{
private readonly ICurrency currency;
public CurrencyCalculator(ICurrency currency)
{
this.currency = currency;
}
public IEnumerable<KeyValuePair<int, int>> CalculateDenominationsFor(int cost)
{
var target = cost;
foreach (var denomination in currency.AvailableDenominations.OrderByDescending(a => a))
{
var numberRequired = target / denomination;
if (numberRequired > 0)
{
yield return new KeyValuePair<int, int>(denomination, numberRequired);
}
target = target - (numberRequired * denomination);
}
}
}
The class has a web front end and an application front end and is used by cashiers.
As it stands; this class exists in a class library project on its own (with currency class and interface). Is this an example of a domain service in DDD terminolgy? (main question) Should it be in a class library named: Core? (the Core of the application). If the answer is no, then what is this class - a utility?
The reason I ask is because I have improved my thinking of this domain recently. However, I cannot see how this very simple class fits in to my domain model.
Update
Before I answer; I have two further thoughts:
1) My understanding of a Domain Service is that it is used when the logic is not a natural fit for an entity and the logic spans multiple bounded contexts/aggregate roots. Is it normal to have a Domain Service, which does not reference any entities or value objects (like in this case)?
2) This specific application is CRUD based and this is the only Domain class. Therefore I am thinking about moving it from the Core project (Domain Model) to the Application Service to simplify it. I guess this would break DDD rules?