15 Tips on JPA Rich Domain Modelling - Thinking In Objects - Not Mappings [For Greenfields] 📎
- Forget about JPA, JDBC & CO for a moment.
- Try to identify concepts and abstractions from the target domain. Use them as candidates for entities.
- Reuse directly the names. Do not obfuscate them with additional technical naming conventions like XYZEntity or "BOs".
- Forget the database mapping and concentrate on good, DRY OO-design and fluent naming.
- Build objects, not structs - put logic into the entities if necessary.
- Forget getters / setters. Think about builders.
- Write unit tests for the business logic and run them, without involving the EntityManager etc. [optional - only if your logic in the entities becomes complex]
- Let the tool (JPA-provider) generate the DDL and the database layout.
- Write unit tests, without mocking out the database, early.
- Provide a lean facade/service layer (the easiest possibility are EJB 3 right now). It should only contain crosscutting concerns.
- Run load and stress tests.
- Import the database into an ER-Tool - optimize the DDL.
- Align the JPA-annotation, if needed.
- Provide orm.xml if required (you should have good reasons for it).
- Go to 11.
[Rich and anemic domain objects are discussed in-depth in the "Real World Java EE Patterns" book. See e.g. page 83 and 259]