Hi all

I am working on a system using NHibernate 1.2 where we use the Repository pattern to provide us with CRUD commands to our database.
In terms of layers separation, we've got:
- A services layer which is here to respond to users of the system whether it is a UI or a web service, this layer uses a generic IRepository implementation and some specific ones (like IUserRepository) to perform data manipulation. This layer is obviously as well dependent upon our business layer
- The business layer that contains all our business objects and that includes data + behaviour.

We chose to try to put as much of the business logic inside the business object themselves as possible.
I don't know if this is a wise move because we made an architectural decision that the domain model cannot use the IRepository interface.

On really tricky issue is how I would go to implement the Table Data Gateway in the domain model without compromising our architecture.

For instance, I may have a method on a Person that says that it will relate a Person object to all of the countries starting with the letter "X".
Because, and as I see it, our domain model only works if objects are some form of Active Records.
Person being an domain model representation of one row of the Persons table.
Now my real issue is that with using the IRepository pattern where it's not available to the domain model how would I get access to all (or some using some kind of specification) from a given type ?

Another big issue I've got with not being able to use the IRepository is that how could I implement some business logic where some objects need to be deleted depending on some business rule. Because I don't have the IRepository instance I woudln't be able to do a .Delete(entity) which would ultimately do a ISession.Delete(entity) ??

Many thanks to any pointer!

Actually, this has been one of the difficulties I ran into when coming to grips with DDD.

Ideally your domain object should only contain domain logic. Your repositories should contain data logic, and if you have logic that needs to be performed across multiple repositories it should reside in a domain service which is also included in your domain assemblies.

In my experience it's best to keep any data related logic out of your domain model, so you shouldn't find methods like IsDuplicate (or similar) that are going to have to examine the contents of a repository to get their info. Instead move these out to your repository or a service.

Sometimes you find yourself with the same multi-repository action need when developing a the application that is going to use your domain - in this case you would generally use "application services" which reside in your application.

Of course, all of this is up for some debate - not everyone agrees on a) how you should do it and b) even if they agree on the approach not everyone agrees on the same descriptive terms.

There's actually a fair bit of info floating around on the web about this stuff, but I'm afraid I can't provide you with any urls as I've had to do a brain purge since I started gathering my info. If you google some of the terms I've provided above you'll find some stuff, no doubt. You could also try reading Domain Driven Design by Eric Evans - good book.

Cheers,

Symon.