JPA Entities and module boundaries

[luciano-fiandesio]

I'm introducing Modulith in an existing Spring Boot monolith to address issues with broken boundaries and circular dependencies. One of the architectural challenges I'm encountering involves JPA relationships. Here's a simplified example:

users
  |__internal
       |
       |_entities
            |
            |__User.java
       |
       |_service
            |
            |__UserService.java
  UserAPI.java

documents
  |__internal
       |
       |_entities
            |
            |__Document.java
       |
       |_service
            |
            |__DocumentService.java
  DocumentAPI.java

There are 2 modules: users and documents. The User JPA entity references Document (@OneToMany). This setup breaks the boundary between the module user and documents, because
Document.java is leaking into the user module.

I can see three possible solutions:

• Move all JPA entities in one module (jpa). This is obviously a very bad idea!
• Maintain references between JPA objects via ID (UUID, Long, etc.) rather than the actual object. This also seems like a bad idea because it goes against JPA philosophy.
• Create module-local JPA entities, that contain only a subset of the attributes of the "main" JPA entity. This feels like a DDD solution, where domain objects are local to the domain they belong to (a document domain object is different depending in which domain it is used).

For example, the users module would be structured as follows:

users
  |__internal
       |
       |_entities
            |
            |__User.java
            |
            |__UserDocument.java (only contains id and name)
       |
       |_service
            |
            |__UserService.java
  UserAPI.java

To me, the third approach is the one that makes more sense, even at the cost of some code duplication.

Are there more design solutions I am missing? I'd appreciate any feedback or suggestions on this approach.

[emileastih1]

Hello,
First, it's crucial to determine whether User and Document are aggregates in your domain model. In DDD, an aggregate is a cluster of domain objects that can be treated as a single unit. Each aggregate has a root (the aggregate root) that is responsible for ensuring the integrity of the aggregate as a whole.

If User and Document are separate aggregates, references between them should be managed carefully to maintain aggregate boundaries and integrity.

Here is my take on the subject for Managing Relationships Between Aggregates :

1. Indirect References via IDs or Value Objects Replace all direct references between aggregates and have indirect reference either by ID as you suggested in your second possible solution either by using value objects as indirect references like UserID and DocumentID instead of the actual Aggregate Reference.
2. Consider a different approach: The second solution is to consider switching from JPA to Spring Data JDBC which is more explicit and firm about applying DDD concepts. You can find a great talk about this matter here: Migrating from Spring Data JPA to Spring Data JDBC