AD/LDAP Integration using Sharp Arch

[David Archer]

Gentlemen,

I've been working on my first Sharp Arch project for a few months now
and it has helped me tremendously in structuring my projects for more
testable code.

My question is more of an architectural/design question that I ran
into while working on my latest project. It is a simple windows
service that does various IT automation "stuff" in a fairly complex,
global environment. Most of the "stuff" (i.e. the core domain) of the
program is dealing with users, groups, various LDAP objects, etc. I
used the lower layers of Sharp Arch to develop the system so I'm
familiar with the IRepository and other idioms of Sharp Arch / DDD.

As you can imagine with this system, it interacts pretty heavily with
Active Directory and also with SQL databases. While I can conceptually
see the SQL persistance being treated as an infrastructure concern,
the actual LDAP objects and how they are manipulated is really the
heart and soul of the system.

During a previous revision of this system, I used the built-in
System.DirectoryServices.DirectoryEntry class directly as various
places throughout the code. I wasn't doing any unit testing and
actually ended up having to do some painful shotgun surgery throughout
the codebase when I found out that DirectoryEntry actually implements
IDisposable. Scratch one up to experience. I also don't like the magic
string Property collection and the ADSI/COM gymnastics required to get
values in/out of it in some places. It just seems better to me to have
a lower layer handle that behind-the-scenes to leave my app to focus
on the real heart of the problem.

For this latest design, I implemented basically an IRepository backed
by AD so I could treat it just like the other NHibernate repositories.
I had my core ADUser and ADGroup classes (containing strongly
typed .NET properties representing all the LDAP properties that I'd
want to modify), the repository classes, and mapping/helper classes
that handles the conversion from DirectoryEntry to ADUser/ADGroup and
vice versa.

Fairly straightforward and testable. Besides the lack of support for
transactions in LDAP and a different concept of "Session", it has
turned out not so bad and pretty easy to work with.

However, I get the feeling that I am rewriting the wheel here with
this custom AD querying/persistance layer. So my question to everyone
here is how would you implement an Active Directory (LDAP) backed
entity and repository in a DDD Sharp Arch project?

FWIW, I did my Google research prior to posting this and found some NH
forum posts unanswered about the same topic:

Post about using NH Interceptors to persist entity objects made up
partially from LDAP and partially from DB:
http://forum.hibernate.org/viewtopic.php?t=992872&highlight=ldap

Another post asking about LDAP-only entities with NH:
http://forum.hibernate.org/viewtopic.php?t=978631&highlight=ldap

I also asked this on Stackoverflow a week ago with no answer.
Currently a 100p bounty on the question:
http://stackoverflow.com/questions/711298/how-do-you-integrate-active-directory-into-a-net-app-using-ddd

Note: I already looked at the new S.DS.AccountManagement classes
in .NET 3.5. However, it still didn't have all the properties I needed
so I ended up having to revert back to the DirectoryEntry.Properties
stuff in some places. For consistency, I ended up with my current
solution using just the DirectoryEntry API.

[Simone Busoli]

I personally have no experience on such a domain, so I cannot suggest anything based on experience. I think this is true for several people so probably that's why you didn't receive any responses yet.

The first things that comes to mind is why you need to create your own domain on top of the LDAP domain which is made of its own entities, services and such.

Presuming you have a valid reason to do so, I think I might have gone down the same path you did, encapsulating the whole LDAP thing and partially delegating operations to it. But even so it would smell quite a bit to me. 

Another option I can think about is creating a standalone domain which satisfies your requirements, eventually duplicating part of the data structures that are in the .NET API and interact with LDAP through an anti-corruption layer, thereby separating totally your domain from the existing API instead of encapsulating it.