CODEWITHSUNDEEP
javaspringjpadomain-driven-designspring-data-jpa
acanimal
acanimal

Reputation: 5020

DDD, domain entities/VO and JPA

I'm starting with DDD and you can image my brain is boiling.

My question is related to my domain objects (entities, VO, ...) which represents my domain concepts/logic and how to persist/retrieve them.

The blue book says the repository is a way to represent collections on domain objects and is responsible to communicate with the infrastructure layer. I read also at some post the infrastructura layer is where you must use hibernate, JPA or whatever.

Then I see this Spring-data-jpa example http://spring.io/guides/gs/accessing-data-jpa/ and I become crazy.

The slogan say Spring-data-jpa is to create repositories easily and the previous samples seems to merge JPA annotations into a domain object (the customer).

Is the sample right? or Am I right?

If I'm right and the domain and infrastructure must be separated, that means to store a customer I must have:

Thanks for any clarification.

Upvotes: 24

Views: 8458

Answers (2)

Tom Hughes
Tom Hughes

Reputation: 201

In DDD, a repository is an object that participates in the domain but really abstracts away some backing store.

If you annotate your domain objects with JPA annotations, your persistence mechanism has bled into your domain. You have tied your domain structure to your persistence structure which is not ideal.

Your JpaCustomerRepository (implements ICustomerRepository) could map the unannotated domain classes (Customer) into an annotated JPA representation - JPA customer. This keeps the annotations out of your domain classes, so is cleaner. It allows you to vary the JPA persistence structure independently of your domain structure. The cost for this benefit is the complexity of the mapping code. 

interface ICustomerRepository {}

class JpaCustomerRepository implements ICustomerRepository {
     void save(Customer customer) {
          JpaCustomer jpaCustomer = map(customer);
          save(jpaCustomer);
     }
}

class Customer {}

class JpaCustomer {}

Upvotes: 17

BAD_SEED
BAD_SEED

Reputation: 5056

I can't see the link you've posted and I have never apply Domain driven design to the Java world. Theoretically what you need is Customer aggregate in the domain layer. In your domain layer there's space for the repository (intended as interface), so you'll have ICustomerRepository. Probably you will have the four prototype for the common persistence issues:

GetById(CustomerId id);
Add(Customer c);
Delete(Customer c);
Update(Customer c);

In the infrastructure layer you will provide the body (for instance CustomerRepository), in the infrastracture layer you can couple yourself with something technological (for example JPA).

Domain layer MUST be completly unaware of technology used in the infrastructure. Doing so you could change completly the implementation details having (almost) no troubles.

Upvotes: 3

Related Questions