DDD - Factory Method and Dependency Injection

Question

Hello,

I' am a bit stuck on a peice of design which i hope this group can help. I am new to DDD and would like an opinion on how to solve this problem.

I have a Currency Value Object that needs to access a repository to get addditional data to make the class complete. The problem (or design issue) is that new instances of Currency can only be created via the Factory Method.

public class Currency
{
internal Currency()
{
}

public string Name { get; set; }

public static Currency CreateCurrencyFromAlphaCode(string alphaCode)
{
Currency cur = new Currency();
//Needs repository to set name etc
return cur;
}

public static Currency CreateCurrencyFromCountryCode(string countryCode)
{
Currency cur = new Currency();
//Needs repository to set name etc
return cur;
}

public static Currency CreateCurrencyFromCountryName(string countryName)
{
Currency cur = new Currency();
//Needs repository to set name etc
return cur;
}

}

I thought that if i need to inject a repository into the constructor then it will make the factory method pointless?

public class Currency
{
public Currency(IRepoistory repository)
{

}
}

How should i design this class given the dependency on the repository, must i make a param on each of the Factory Methods to accept a repository?

Thanks

Answer 1

Without knowing some more about the context of your application it's difficult to be certain so forgive me if this is slightly off target, but it seems as though there are two potential issues with your design here.

Firstly you are injecting dependencies into a class that is presumably going to be used in your domain layer. Injecting dependencies into the domain layer or into dependencies of the domain layer is often seen as a symptom of a design flaw somewhere in your application.

Secondly, your currency object is taking on two responsibilities. Firstly it's being a currency (obviously), and secondly it is responsible for the creation of currencies.

To fix these issues, can you break the factory methods out of the currency class into a 'higher' layer of your application? If so you may find that everything starts to get easier as you can inject the repository dependencies into the factory with no problems. This may mean refactoring your domain layer code so you are passing 'ready built' currencies in there rather than currency codes, country codes etc, but I think that isn't a bad thing in itself. The domain layer should presumably care about a 'Currency', not necessarily about a 'Currency Code'.

Answer 2

Why don't you move the currency building outside of the currency class? I don't like the name, but you might try something like CurrencyBuilder. It might look like this:

public class CurrencyBuilder {
  private IRepository repository;

  public CurrencyBuilder() : this(new DefaultRepository()) {
  }

  public CurrencyBuilder(IRepository repository) {
    this.repository = repository;
  }

  public Currency FromCountryCode(string countryCode) {
    string currencyName = repository.GetCurrencyNameByCode(countryCode);
    if (currencyName == null)
      throw new CurrencyCodeException(countryCode + " not found");

    Currency c = new Currency();
    c.Name = currencyName;

    return c;
  }
}

Using this setup, when you call 'new CurrencyBuilder()', it will use your default repository instance. However, for testing, you can pass a mock repository into the constructor.

Hope that helps, and stick with it. For what it's worth, this is not a great example where DI will help a lot. So, if you feel unsatisfied at the completion of this task, don't give up on DI straight away. As you get more comfortable with it, it's usefulness will become more apparent.

Answer 3

If "repository" means "relational database", I'm not sure it should be your first choice here. After all, the number of currency codes is relatively static. They won't be changing that often, so I wouldn't think that you should have to pay the roundtrip to the database every time you create one.

I wonder if either a static data structure that's loaded on start-up from either a database or text file would be a more efficient choice. It'd be one less dependency as well.

Answer 4

I responded to this on the DDD list where you asked it as well, but I'll repeat my concerns here too.

I think you're getting the roles of a Factory and a Repository confused here.

Your methods named, for example, CreateCurrencyFromAlphaCode, actually look like they should be, for example, FindCurrencyByAlphaCode and they should exist in a Repository, not in a Factory. A Factory is used for creating objects that don't already exist in your persistence layer (or for instantiating objects from data you've already received from your persistence layer).

Also, your AlphaCode actually sounds like an Identity, so, if you did want to continue retrieving Currencies from your persistence layer, then I'd suggest your Currency is most likely not a Value Object, but rather an Entity.

Without knowing more about your domain, it's hard to know if this is a correct design decision or not. I'm inclined to think that duffymo's response would serve you better and then you wouldn't need to worry about fetching from a data store each time at all.