...
- Should module be decoupled from each other to the extent that they can possibly have their own database? Implications: no foreign key relationship, possible independent hosting and deployment, lack of transaction, cannot do joins?
- What the extent of vertical slicing of modules? (i.e. does it include the presentation, action)
- Which layers in a module are accessible to another module at the compile time?
- Entities in one module would logically refer to entities in another module. Should these relationships be modeled at the entity level, as well? If not how would the relationships be created?
- Which module would host the page when data displayed is from two functional modules?
- In case of One-to-One/One-to-Many/Many-to-One (logical) relationships between entities how to decide who refers to whom? How to avoid cyclic relationships between modules?
- If there is no domain relationship between entities in different modules. A parent entity (in module A) has child entity (in module B), when the child entity is created, how does parent entity get the id for it?
- When entities are updated in different modules, would transaction be taken care of? Would it be the case when we use OSGI?
- If there is a requirement which involves joining data across different modules. How would we resolve such issues? Where should this code lie? How would we do this using HQL?
- Each module potentially has some reference data in it. ReferenceData is something which doesn't change very often. If and when we need it, what should be the caching strategy for reference data?
- Should each module have their own session factory?
- Should each module have their own session?
...