...
- 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. In such a case should there be hibernate based relationship between entitiesShould these relationships be modeled at the entity level, as well?
- Which module hosts would host the page which displays 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?
- If we partition modules only at the service layer (below presentation layer), we would have a monolithic website. Is that a problem?
- 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?
...