Design recommendations for complex AD-drivers pros and cons


I'd like to get some input on a design question.

Assume I have very complex policies for different objects in different OUs, e.g. for two different parts of an organisation.

To me it seems cleaner to create two instances of AD-driver to separate the complexity better, not only put them in different policies and different packages.

What are the  pros and cons?

E.g. is there large overhead to have two instances instead of one? 



  • The biggest problem with having two AD drivers is that only one can do password sync from AD.

    I have not yet seen a design that convinced me to do two AD drivers.

    As long as you name your policies and keep a good structure in the driver there should be no problems.

  • You can handle different policies in the one driver relatively easy.

    Handle different locations in AD  from placement policy.

    If you have clear definitions of how to separate users (with different policies) on a logical level - you can handle it.

  • Agree with the others.
    It is no real issue to have different logic for different OUs in AD.

    Recall that target system drivers should be primarily for data transport.

    If you are doing a lot of calculating and logic in a driver like AD, you might want to review whether it is better to seperate out some of the non AD specific code to a null driver that allows you to better organise the business logic..
  • Sounds like a good architecture to me.

    Just one follow up.
    Should I still keep lots of logic in the same null-driver within different packages to e.g. keep overhead down?

    I myself like simple more object-oriented structure (maybe because I'm used to object-oriented programming), where I put isolated responsibility (SOLID-principles) in an object or component, which for me in this case is a driver.

  • Each driver is effectively another thread, so positive.

    But you can get so many drivers, and dancing events between them, that troubleshooting is tricky.  Negative.