This is more a general ORM question than NHibernate-specific, but anyway ...

We have a highly extensible application. We are thinking of encouraging or even requiring developers, both in-house and our customers, to organize classes first by "application module". Our off-the-shelf application has 5 or 6 "modules", and customers often add more functionality that are really new "modules" in themselves.

Currently, we are putting all of our product's entities into one namespace. To make the application more modular, should we divide up the entities into separate namespaces? The entity classes are generated, so tracking which module they are in, and which modules the entities they relate to, can be fairly complicated. The "modules" are not all independent -- they reference each other, so they'll still need to be in the same assembly at least.

Does anyone else divide up their entities into separate namespaces by "application module", even if the modules are not all independent? Does anyone else have highly extensible applications where they want to have some kind of modular structure as the application grows?

I always group things by logical separation... if they're all related domain objects, then it might make the most sense to just keep them in your current "core" assembly and namespace. However, if they're fairly distinct and you can draw clear divisions between responsibilities (even if certain responsibilities require domain objects from other responsibilities), then grouping them is nice.

System is a good reference... one assembly with some really nice groupings by responsibility.

Just don't get carried away ;-) I guess my rule of thumb is that if I can imagine them being in their own assemblies, they at least get their own namespaces for now.