Applicazione dei principi DDD in un servizio Web RESTish

1

Sto sviluppando un servizio web RESTish. Penso di aver avuto l'idea della differenza tra aggregazione e composizione. L'aggregazione non impone il ciclo di vita / l'ambito sugli oggetti che fa riferimento . La composizione impone il ciclo di vita / l'ambito sugli oggetti che contiene / possiede .

Se elimino un oggetto composito, vengono eliminati anche tutti gli oggetti che contiene / propri, mentre l'eliminazione di una radice aggregata non cancella gli oggetti di riferimento.

1) Se è vero che l'eliminazione delle root aggregate non elimina gli oggetti referenziati, che senso ha a non avere un repository per gli oggetti di riferimento? Oppure le radici aggregate come termine che si riferisce a ciò che è noto come oggetto composito?

2) Quando crei un servizio web avrai più endpoint, nel mio caso ho un'entità Book e un'altra chiamata Comment . Non ha senso lasciare i commenti nella mia domanda se il libro viene cancellato. Pertanto, il libro è un oggetto composito. Suppongo che dovrei non avere un repository per i commenti poiché ciò potrebbe infrangere l'applicazione del ciclo di vita e le regole che potrebbero avere la classe del libro. Tuttavia ho URL come (solo esempi):

GET /books/1/comments
POST /books/1/comments

Ora, se non ho un repository per i commenti, vuol dire che devo caricare l'oggetto book e quindi restituire i commenti di riferimento? Sono autorizzato a restituire una lista di entità Comment da BookRepository, ha senso? Il repository di Book potrebbe diventare piuttosto grande con tutti i tipi di metodi. Sono autorizzato a scrivere JPQL (query JPA) che indirizza i commenti e non i libri all'interno del repository? Che dire dell'impaginazione e del filtraggio dei commenti. Quando si aggiunge un nuovo commento innescato dall'endpoint POST, è necessario caricare il libro, aggiungere il commento al libro e quindi aggiornare l'intero oggetto del libro?

Quello che sto facendo attualmente è avere un proprio CommentRepository, anche se i commenti vengono cancellati con il libro. Potrei aver bisogno di qualche direzione su come farlo correttamente. Dato che stai esponendo non solo gli oggetti root nei servizi RESTish mi chiedo come gestirlo nel back-end.

Sto usando Hibernate e Spring.

    
posta Andy 03.10.2013 - 18:26
fonte

1 risposta

1

Non hai altra scelta che interrogare i commenti per l'ID del libro quando hai a che fare con RDBMS. Per il database dei documenti è una storia diversa e questo è il motivo per cui i database dei documenti sono più adatti per DDD rispetto agli RDBMS.

Basta ricordare, lo ripeto di nuovo, DDD non riguarda i repository e qualsiasi altra particolare implementazione che Eric Evans ha menzionato nel suo libro. Se parlerai con lui, imparerai che a volte si rammarica del fatto che ci siano stati così tanti dettagli di implementazione inclusi nel libro. Le persone pensano troppo ai repository e alle specifiche rispetto ai domini reali ... A meno che la tua applicazione non abbia un enorme panorama multi-dominio, nulla ti impedisce di pubblicare query come session.Query.Where (c = > c.BookId == myBookId) giusto nel tuo servizio REST. Il tuo servizio è già un livello di servizio, un'altra astrazione sarà un overkill. Hai già menzionato che gli archivi crescono e scommetto che la maggior parte dei tuoi metodi di deposito sono chiamate di accesso ai dati su una sola riga. Nessun esperto di dominio dirà che è giusto.

    
risposta data 17.10.2013 - 20:05
fonte

Leggi altre domande sui tag