architecturedomain-driven-designdesign-patterns

Programming pattern / architectural 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!


Solution

  • 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.