Should domain objects be free of JPA annotations?

[mackapappa]

In #73 this question showed up:

A question if I may. Just wondering about these changes to the domain model.. Is mixing JPA/ORM into the model considered good practice? I would think not, but what is the argument? Would it perhaps be cleaner to do OR mapping inside the repository implementations?

which was answered by:

Good question. Prior to this refactoring the Hibernate mapping was also closely tied to the domain objects even though the connection was not in the java-code itself but in a xml-file. So I would argue that we have not changed the design and that your question is about if this is a preferable design or not.

What do you think? Should JPA annotations be separated from domain objects or not?

[orende]

@patrikfr I believe you have shared some good input on this in the past. Would you like to add your opinion here?

[mackapappa]

Good comment!

I guess another option for separating the domain model from infrastructure code is to create some kind of DTO-layer in between. What do you think about this solution? Does it make the separation between domain- and infrastructure-code clearer? Is it worth the cost?

[patrikfr]

Not sure, probably not. I'm afraid it will just feel convoluted, raising more questions than it will provide answers.

(I do, however, find it somewhat troubling that the default persistence tech is ORM. I think it's a rather poor choice for storing domain object models. But that's opening a whole other can of worms, I suppose.)

[orende]

I personally find that can of worms quite interesting! While migrating the project from Hibernate to JPA, I did actually make an experimental branch in which I replaced the ORM completely with JDBI. In this branch, the models were completely decoupled from the repository implementation, and there was no added DTO layer. Do you think that would have been a better approach than using an ORM for this project?

[patrikfr]

This could make the infrastructure integration cleaner and using a more lightweight lib here can be beneficial, but it also depends on the complexity of the domain model (and its mapping). What troubles me more is the concept of mapping an object graph to a relational data model.

[dhasilin]

I agree on ORM being not the beast fit, but when we need to combine commands and queries in one data source for simplicity it is commonly used.

In long live projects Im really looking into moving orm mappings out to enable model to evolve without constraints of data storage, sometimes it is easier to write few joins and fetch data needed, not to worry about model inner design, and in parallel change models easily when more and more details are refined.
And it is nice when you could change the model to fit into new requirements/ideas/knowledge
crunches without need to run database migrations, especially when you obliged to run them with backwards compatibility support.

So for me its not about changing data source, but about change model separately and frequently, run them on different envs, test them, map them to external specifications (APIs) and ofcourse having different model per problem from same entity (not sure of that is good practice at all - and is more valuable when project has fewer models to store but tons of use cases/logic, so one dataset could be represented in different models per use case if needed.)

Main challenge here for me is to have clean mapping without exposing encapsulated data or using contraversial memento pattern to handle updates to models.
Extra mapping layer is always no fun

Looking forward into other approaches, like spring data jdbc (still not so editable model) or simple repo/orm-dto using package access constructor to create a model (same mapping different places)

Sorry for long and a bit hectic comment, i will structure my mind it and make it shorter next week

[DanielWillian]

Prior to this refactoring the Hibernate mapping was also closely tied to the domain objects even though the connection was not in the java-code itself but in a xml-file. So I would argue that we have not changed the design and that your question is about if this is a preferable design or not.

Infrastructure (the xml-file) depending on domain code is fine. In annotating domain classes with JPA now domain depends on some level of the infrastructure. There's schema information on it. This is a single project but if it was a multi-project, the domain project would need a dependency on persistence API.

Ideally, there should be as little dependency on frameworks on domain code, but I think some level of pragmatism can be beneficial. For example, adding transactional annotations, logging or lombok, maybe even annotations to be used by aspects for tracing and metrics. But I think it is too much to add JPA annotations on entities.

A similar scenario to me would be if some REST API was returning a domain class, not ideal but manageable, and a requirement came up to change the API you start adding Jackson annotations to the domain class. I would say to just use a DTO, for both cases, let domain entities be free of framework annotations.

[mackapappa]

Infrastructure (the xml-file) depending on domain code is fine

Is this really always the case? If you have a domain object annotated with JPA-annotations and refactor the annotations into an xml-file, isn't the dependencies exactly the same except that you moved it's definition from one place to another?

[DanielWillian]

Fine as in at least it is the infrastructure layer that depends on the domain layer and domain layer does not have a dependency on any infrastructure code definition. The dependencies are not the same, domain would need to depend on at least a persistence API if you would annotate the domain classes. Such is the case that even the code mentions some additions due to the underlying infrastructure.

Using a domain class in the XML file is fine on the dependency side because it is an infrastructure layer decision to depend on domain for this, which it can do, naturally, but I would not personally do it. If I were to create an XML file (I would not, I would annotate a DTO) I would create a DTO to be written in the XML.