We have an application that, along with many things, does some changes to Active Directory (add/remove user from group, change attribute values on user, etc).
We are now in the process of redesigning it (from “spaghetti-code” into a more layered solution). The Active Directory management functions is something we would like to abstract out to some degree in the domain layer, but at the same time, most functions are very technology dependent.
Should we place all Active Directory access code in the data access layer along with our DB-access, or is it ok to create a active directory library of functions and call into this library directly from the domain model? That makes the domain object persistent aware and that’s probably a bad idea?
Or should all Active Directory access instead be performed in the service layer instead and not even involve the domain layer?
Domain Models should be technology-agnostic, so don’t put your AD code in the Domain Model.
In essence you could say that AD code is just another form of Data Access, so it belongs in the Data Access Layer (DAL). However, it doesn’t belong together with your database module, as that would be a violation of the Single Responsibility Principle (SRP – it applies to modules as well as individual types).
Instead of bundling it together with the database access, implement it in its own library. Conceptually, it belongs in the same layer, but it does different things, so now you have two libraries in the same layer. That’s absolutely fine – you can have as many libraries in each layer as you need.
In the Domain Model, treat the AD access (and the DB access) as abstractions. Abstract Repositories are the default approach. The AD library will contain implementations of the AD Repository, and the DB library will contain implementations of the DB Repositories.
This fits well with Domain-Driven Design and the concept of an Anti-Corruption Layer.
You can use Dependency Injection (DI) to wire the concrete Repositories up with your Domain Model.