Where to place technology specific things in domain model?

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.

So you mean that it should be placed in the service layer instead? Or where do you suggest it should be placed? I'm new to domain model (have been reading many articles and books on the subject but still doesn't feel quite comfortable yet ;)..

Per 2010-01-05 09:03:18

That makes sense. So you mean that I should have domain objects for User, Group etc. in my domain layer and by utilizing something like the virtual proxy pattern I add technology specific concerns to my domain objects (like group add/remove from user)?

Per 2010-01-05 09:28:59

Put User and Group in your Domain Model if they make sense in the context (they probably do). No need for a virtual proxy though, as all Domain objects should be POCOs. Repositories simply expose methods that allow you so retrieve or modify the Domain objects from the underlying storage.

Mark Seemann 2010-01-05 09:36:03

Do you mean that the domain objects should be aware of the Repository? I'm bending my brain inside out here, but i cannot get a clear view of how to correctly implement a domain model... ;). There seems to be many views on how a domain model should be implemented (or I'm just misinterpretating them). I wish someone could hold my hand while designing.. ;)

Per 2010-01-05 09:43:57

Domain Objects that are aware of the Repository are using the Active Record pattern, but this is not currently in vogue. I prefer Persistent Ignorant POCOs, which means that the Repository knows about the Domain Object - not the other way around.

Mark Seemann 2010-01-05 10:02:09

Take a look at Jeremy Miller's overview article in MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/dd569757.aspx

Mark Seemann 2010-01-05 10:03:26

I have read that article earlier, but I'll take a look again. In the meantime, if I don't use Active Record (which I'm not planning) as you suggest, but instead use mappers, where do I put the technology specific details without using something like "Virtual Proxy"?

Per 2010-01-07 12:57:27

You can implement Repositories and other interfaces in separate libraries and make sure that your Domain Model only talk to the interfaces. Then use DI to wire up your application with the desired concrete types for the abstractions.

Mark Seemann 2010-01-07 13:09:28

Ok, now I think I'm beginning to grasp things. I was just reading about IoC and DI... Maybe I should buy your book by the way? ;)

Per 2010-01-07 13:22:52

Well, I wouldn't mind that :) Seriously though, the book is aimed at introducing DI and related concepts to .NET developers, while also providing guidance for readers with previous knowledge of DI, so I think you fit the target audience.

Mark Seemann 2010-01-07 13:40:13

ansaurus

tags:

views:

answers:

Where to place technology specific things in domain model?

related questions