CODEWITHSUNDEEP
jpadnsdomain-driven-designonion-architecturehexagonal-architecture
redzedi
redzedi

Reputation: 1995

Jpa Entity as Domain Model

As per recommended practices documented for DDD or Hexagonal architecture - The domain Model should be separate from the data model representations that are more tied with actual technology used( table/column names, joins, etc, JPA annotation). A practical issue here is - how do you do things like optimistic version control in this model? Say you have a domain service that does read-->update-->save on a domain model. Now the JPA entity might have a version column that it can't pass upwards. Thus when the save call comes to the repo and the repo essentially once again does ( model --> entity) conversion and read+update, it will have no way to tell which version of the entity was read originally.
A secondary issue is the perf consideration of this involving a few extra reads here

Upvotes: 4

Views: 1589

Answers (2)

Luca Masera
Luca Masera

Reputation: 732

You can do different things:

  • Relax the rule that the domain model should be split from the persistence model. Nobody says that the DDD has "fixed rules" that should be strictly followed. That means that you'll use the same JPA entities inside your domain, modelling them following the DDD rules and not the JPA ones. Hence, no get/set for each field, embedded entities for all the ValueObject and so on. But, as you know for sure, if the domain is complex you have to fight a lot to avoid the JPA pitfalls.
  • Edit: I would not suggest this solution, because it's a lot of extra work. As cache the one of hibernate could be used, it makes the things simpler. Store your JPA entity in a cache before transforming it into the Domain entity. It looks stupid, but at the end the separation between the Persistence Layer and the Domain Layer allows you to implement the repository in any way that is useful for you. So, if your JPA entity has a Version, the simplest way that it comes in my mind to manage it is to have a kind of cache inside the implementation of the repository. Then you can proceed like this:
    1. read the JPA entity
    2. store it in the cache
    3. send the resulting Domain entity for the updates
    4. get back an updated Domain entity
    5. update the JPA entity that you have in the cache
    6. store it, leaving the version handling to JPA
  • Ignore the JPA stuff and use the SQL directly. You have already the Domain entities, writing the SQL gives you the freedom to perfectly tune the code for the your needs, without the overhead of the JPA layer. You can still use the cache solution, where you store for each Id the Version of the Entity that you've read and use it in the same way as before.

There's no silver bullet solution for a concrete usage of DDD into a project. It depends on your needs and desires.

Should I finish fast? Can I invest a bit of time in a persistence to domain transformation layer?

Is this code used/changed by someone later, that can do weird things if I don't put 'locks' on it?

Am I trying to create a pure DDD implementation?

Should I relax some rules to slowly introduce the DDD in my project, or to my team?

Interesting reading about JPA and Domain entities:

Upvotes: 5

Utkarsh Sharma
Utkarsh Sharma

Reputation: 1

There are different ways to do it. It mostly depends on where your application/layer lies in the architecture. Most time the application/layer that communicated with the entity model is at the foundation level. You are not obliged to create a separation when that serves no purpose. The proof of communication will be always the layer that will talk to this layer hence I do not see a need of creating one more transition. You could just pass the entity model/instance data.

Upvotes: 0

Related Questions