Where should site configuration data repositories be located?

We have a number of NHibernate Entities that map to data that is specifically for configuration of a multi-tenant web application. These entities exist in the Domain project with the rest of the NHibernate entites.

The thing is, all of the rest of the entities are business-related, where these entities are configuration-related. Does it make more sense to have them in the Web?

The reason I ask is because I'm faced with the issue outlined in this question: How to supply RequestContext data to the constructor of a domain object? , where I need data from the request context supplied in 开发者_如何学Cthe constructor of a domain object. The trouble is that I don't want to reference the Web project from the Domain project. If I was getting the config data directly from the Web project, then this wouldn't be an issue.

edit: "Does it make more sense to have them in the Domain?" corrected to ".. in the Web?"

Personally, for my projects I quickly break out my repositories, models, etc. into distinct assemblies (not just based on busness/configuration/etc.).

So in a situation where a repository needed access to information from the RequestContext, I would have a separate repository set up for this configuration data, and in a separate assembly from my business repositories/objects.

Even within my domain objects (and in our health care project, we have dozens), we quickly figure out the main seams where we can break things up - i.e. a component that deals specifically with shaped data does not need to carry the weight of our entire domain, so we explicitly set up the mapping objects we wish to use in our config file, and keep our domain objects broken down by logical function.

In short, I would not blink in considering breaking out your configuration entities into a separate project/assembly (generally, our assemblies include the generic repository interface, our concrete repository, NHibernate mappings, and the relevant model).