DDD, domain entities/VO and JPA

Question

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/log

Answer 1

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.

Answer 2

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 {}