Here is an interesting problem. I want to package a domain model with specific functionality, but I don't want to constrain the model users of this functionality will use.
For example, let us take security systems and the User entity. I have yet to see any two projects that had identical users entities.
Now, the concept of a user in a security system is pretty important, I would say. But no important enough that I would want to force my idea about what a user looks like on an innocent domain model.
Now really. We can use the usual OO abstractions to handle this. Check this domain model:
The only requirement that this security system has is to have a User entity that implements the IUser interface. The only requirement that this has is to expose a single property, SecurityInfo, which describe the user. Notice the SecurityIdPropertyName there, it is there to allow us to do queries based on the security id without forcing a structure on the user entity.
How do it actually work, however, is more interesting.
At initialization time, we perform Mapping Rewrite and tell NHibernate that the concrete implementation of IUser in all its associations is mapped to the User entity from our project.
This means that we get to have the cake (separate domain models) and eat it (rich domain models without constraints).