Programming pattern / architectural question

Question

I am currently working on a project where I have a BankAccount entity for some other entity.

Each bank account is a reference to a bank entity, an account number, and optionally an IBAN.

Now since an IBAN can be validated, how can I ensure that when the IBAN is set for an account is valid? What would be a clean architectural approach? I currently have a domain layer without any reference to any other layer and I like this clean approach (I was inspired by Eric Evans DDD). Fortunately, the IBAN validation can be performed without accessing any outside system so in this case I could have something like

public class BankAccount
{
  public string Iban
  {
     set { // validation logic here }
  }
}

But now I was thinking what approach I would use if the IBAN validation requires an SQL server check for example, or an external dll. How would I implement that? Would I create an IBAN value object that is passed to a service, that decides whether the IBAN is valid or not and after that set it to the BankAccount entity? Or would I create a factory that is allowed to instantiate IBANs and perform validation before?

Thanks for your help!

Answer 1

I would use some form of Inversion Of Control.

To be specific, I would have an interface called IIBANValidator. The various means of validating the IBAN should implement that interface. For example:

interface IBANValidator {
    Boolean Validate(string iban);
}

class SqlBanValidator : IBANValidator {

    public bool Validate(string iban) {
        // make the sql call to validate..
        throw new NotImplementedException();
    }

}

Then, I would have a method in my BankAccount class which accepted an object that implements IIBANValidator and the IBAN number and was structured like (not optimized by any stretch):

Boolean SetIBAN(IIBANValidator validator, String iban) {
  Boolean result = false;
  if (validator.Validate(iban)) {
    Iban = iban;
    result = true;
  }

  return result;
}

At this point your BankAccount class would not have to have a dependency on your validators, you could swap them out at will, and ultimately it's very clean.

The final code would look something like:

BankAccount account = new BankAccount();
account.SetIBAN(new SqlBanValidator(), "my iban code");

Obviously at runtime you could pass any validator instance you wanted.