CODEWITHSUNDEEP
jpadomain-driven-design
josev.junior
josev.junior

Reputation: 449

DDD, JPA and non-default constructors

DDD says that you domain models needs to be expressive and say what they need. With that in mind I created the following class:

@Entity
public class User{
    @Id
    @GeneratedValue
    private Long id;

    private String userName;
    private String password;

    public User(String userName, String password) {
        /**set the values*/
    }

    /** Validations, getters and business methods*/

With this constructor I tell that the minimun needed to build a new User object.

The problem with that approach is that JPA needs a non-argument default constructor to instatiate the class by reflections. In this case do I have to forget about that DDD sugestion or is there a workaround?

Upvotes: 1

Views: 499

Answers (2)

Murilo Carlos Cardoso
Murilo Carlos Cardoso

Reputation: 57

In your specific situation you can make the non-argument constructor private. But soon another JPA requirement will force you to make another workaround;

voiceofunreason gave you the right answer. The right way is to have an adapter in the infrastructure/persistence layer that receives your domain object and then convert it to a JPA anemic model and vice versa.

Some other options that fits better without too much conversions:

1 - Spring Data JDBC is trying to absorb Aggregates concept

2 - Persist your aggregate as a json in a relational database. Vaughn Vernon proposed an implementation -> https://kalele.io/the-ideal-domain-driven-design-aggregate-store/

3 - Document oriented database such as https://www.mongodb.com/ among others...

Upvotes: 2

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57259

In this case do I have to forget about that DDD sugestion or is there a workaround?

There isn't really a good answer here. There's a tension at work when we try to mix objects with mutable, encapsulated state, and persistence (ie: storing the authoritative copy of state in some anemic durable store).

The "right" answer is that we don't use an O/RM to load domain entities from the durable store; the O/RM loads a DTO, and we copy information from the DTO into the domain object. Similarly, to save, you extract information from the domain entity and copy it into the DTO, then save the DTO.

In other words, the O/RM loads an in memory representation of an anemic data structure.

In practice, it's a lot more common to couple the entity state to the O/RM, implementing within the domain entity whatever interfaces the O/RM needs to do its work.

The trick is to make sure that you can decouple your implementation from the O/RM when the O/RM assumptions start to get in the way. For instance, you should be able to easily change a specific aggregate from using a relational data store to using a document data store without requiring a rewrite of your entire system.

Upvotes: 0

Related Questions