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:
Code:
List<TaxRates> allTaxRates = repository.GetAllTaxRates();
accountTransaction.CalculateTax(allTaxRates);
// the accountTransaction is self-aware of additional information that
// would allow it to select the appropriate tax rate from the collection.
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