DDD, Domain Entities/VO und JPA

Question

Ich beginne mit DDD und Sie können Bild mein Gehirn kocht.

Meine Frage bezieht sich auf meine Domain-Objekte (Entitäten, VO, ...), die meine Domain-Konzepte/Logik darstellt und wie sie erhalten/abgerufen werden.

Das blaue Buch besagt, dass das Repository eine Möglichkeit darstellt, Sammlungen auf Domänenobjekten darzustellen und für die Kommunikation mit der Infrastrukturschicht verantwortlich ist. Ich lese auch auf einem Post die Infrastructura-Ebene, wo Sie Hibernate, JPA oder was auch immer verwenden müssen.

Dann sehe ich dieses Spring-Daten-Jpa Beispiel http://spring.io/guides/gs/accessing-data-jpa/ und ich werde verrückt.

Der Slogan sagen Spring-data-jpa ist einfach Repositories zu erstellen und die vorherigen Proben scheint JPA-Annotationen in ein Domänenobjekt (customer) zu verschmelzen.

Ist die Probe richtig? oder habe ich recht?

Wenn ich Recht habe und die Domain und Infrastruktur getrennt werden müssen, das heißt, einen Kunden zu speichern, muß ich haben:

• eine Customer Klasse in meiner Domain-Schicht (das steht für einen Kunden und verfügt über alle logische Operationen)
• eine CustomerRepository un meine Domain Schicht (das abruft oder speichert Kunden von Infrastrukturschicht)
• eine Customer Klasse in Infrastrukturschicht, wahrscheinlich mit @Entity kommentierte
• Einige CustomerReposityJPA, die wissen, wie Kunden aus der Datenbank gespeichert werden.

Danke für jede Klarstellung.

Answer 1

Ich kann den Link nicht sehen, den Sie gepostet haben, und ich habe Domain-driven Design nie auf die Java-Welt angewendet. Theoretisch was Sie brauchen, ist Customer Aggregat in der Domain-Ebene. In Ihrer Domain-Schicht ist Platz für das Repository (als Schnittstelle vorgesehen), so dass Sie ICustomerRepository haben. Wahrscheinlich werden Sie die vier Prototypen für die gemeinsamen Persistenz Probleme haben:

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

In der Infrastrukturschicht Sie den Körper (zum Beispiel CustomerRepository), in der infrastracture Schicht mit sich selbst kann etwas technologischen (zB Sie Paar liefert JPA).

Domänenebene MUSS sich der in der Infrastruktur verwendeten Technologie nicht bewusst sein. Auf diese Weise können Sie die Implementierungsdetails (fast) problemlos ändern.

Answer 2

In DDD ist ein Repository ein Objekt, das an der Domäne teilnimmt, aber tatsächlich einen Backing Store abstrahiert.

Wenn Sie Ihre Domänenobjekte mit JPA-Anmerkungen versehen, hat Ihr Persistenzmechanismus in Ihre Domäne geblutet. Sie haben Ihre Domänenstruktur an Ihre Persistenzstruktur gebunden, die nicht ideal ist.

Ihre JpaCustomerRepository (implementiert ICustomerRepository) könnte die nicht-named Domain-Klassen (Customer) in eine kommentierte JPA-Darstellung - JPA-Kunde zuordnen.Dies hält die Annotationen aus Ihren Domain-Klassen heraus und ist somit sauberer. Sie können die JPA-Persistenzstruktur unabhängig von Ihrer Domänenstruktur variieren. Die Kosten für diesen Vorteil sind die Komplexität des Mapping-Codes.

interface ICustomerRepository {} 

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

class Customer {} 

class JpaCustomer {}