I have implemented NHibernate using a DDD model, where I have separate namespaces for the domain, the repository (DAO) layer, and a service layer.

Business logic primarily resides in the domain. Business logic in the service layer handles issues that go across domain entities.

The service layer populates object graphs by using repository methods, which are NHibernate aware.

The domain is agnostic/unaware of the persistence logic/NHibernate, and if possible I'd like to keep it that way.

The problem I am encountering is with code tables in the database, for example, a table containing the possible tax rates in the system, or types of account transactions. Both code tables have a number of columns each. (In the past, for simple code tables with single values, I've just mapped them to enums--not an option for these information-rich code tables.)

Currently to access these codes tables I need to pass them as collections to entity methods in the domain. For example, for the code table TaxRates (mapped to the TaxRate class in my domain), I would call the repository to find all TaxRate objects, and pass that collection into a domain method:



In conclusion, the only 2 choices I see are:

* the above, which could result in a lot of collections getting passed around within the entity business logic; or
* loosening the boundary I've set on the domain, and allowing it to call the repository to populate "code tables" as needed on the fly.

Any recommendations would be appreciated.

Thanks,

David

On thinking about this further, I'm thinking of creating a singleton class within the domain that IS repository aware, and have it expose properties containing each code table as a collection, something like:



Again, any recommendations appreciated.