Hi all,

I'm currently working on a large enterprise system and am faced with a difficult decision on how to structure a set of applications. Let me give you the lay of the land. We have 2 main applications: the frontend (a web application) and a backend application (stand alone java app). Both of these applications share the same legacy database. Both of these applications share some entities; for instance Member which is backed by a single member table.

How this Member entity is used differs between the applications however. For instance there is business logic which is applicable to one application but not the other. An example could be member.login() which is only applicable to the frontend application.

Additionally it may be the case that certain properties and/or relationships are only required for certain applications. Continuing with the member example there might be a relationship from Member to a set of loginHistory objects. In the backend application we may not care about loginHistory and hence it shouldn't be a mapped relationship. This means the object graph will be different between the applications. Also lazy fetch and 2nd level cache may be configured differently between the applications.

An obvious solution is to have a shared kernel (DDD) containing the common entity (with common properties, logic and relationships) and then sub-class it for use in different contexts. So as the example stands we would have a base Member entity with all the common stuff:



and then 2 sub-classes with application-specific logic, relationships and properties (please note the packaging differences):





This scenario implies that there are 2 hibernate mappings for the same entity. Now this is all fine and dandy but when it comes to managing the hibernate mapping files things become tricky. For instance there will be duplication across the mapping files which will need to be maintained. The common properties will be mapped in 2 places and there is a chance for discrepancies and error.

We thought about making a common mapping template and then translating at build time to merge it with the application-specific mappings, but this obviously complicates things even more. For instance, changes to the common mapping template could cause property name collisions in the application mappings.

So, my question is, how are other people handling this scenario? This cannot be an uncommon situation as i'm sure other enterprise-size ORM implementations face a similar issue. Eagerly awaiting your responses!

<bump> No one else has encountered this?