2015-09-10 16 views
5

Lavoro su un'applicazione back-end che espone una API REST e io (prova a) uso Domain Driven Design nel mio progetto.Le classi di infrastruttura API possono far parte del dominio in DDD?

L'API REST funziona su un set fisso di classi di dominio. Per ogni radice aggregata del dominio esiste un endpoint REST separato. Tuttavia, nonostante tutti gli sforzi, ci sono casi in cui nuove classi, non derivanti dalle classi di dominio (classi infrastruttura) emergono, ad esempio:

  • una classe di partecipazione stati delle operazioni batch [{"id": 1, "status": "success"},{"id": 2, "status": "failure", "message": "detailed message"}]
  • una classe con le colonne scelto dall'utente [{"column": "id", "order": 1}, {"column":"created", "order": 2 }]

Ora due opzioni:

  • E 'ok per avere l'API REST esporre le classi che non fanno parte della il dominio?
  • o queste classi dovrebbero diventare parte del dominio?
+1

Penso che sia del tutto normale esporre contratti specifici per il livello. Ad esempio, le DTO sono generalmente definite nel livello applicazione ... – plalx

risposta

5

Non provare a creare l'API REST direttamente sul modello di dominio. Ci sono un certo numero di responsabilità di cui hai bisogno per una simile interfaccia che rovinerebbe il tuo modello di dominio. Per esempio. controllo delle transazioni, sicurezza, convalida dell'input sono cose che probabilmente sono necessarie, ma che non appartengono al modello di dominio.

Questo è ciò che i servizi di applicazione sono lì per.

Costruire un sottile strato diattorno al modello di dominio che contiene i servizi applicativi (spesso chiamato servizio di livello). I servizi dell'app sono i client diretti del modello di dominio. Solitamente sono organizzati intorno agli Casi di utilizzo anziché aggregati. Ora la tua API REST è il client diretto dei servizi app anziché del modello di dominio.

Le due classi che si menzionano si adattano bene anche al livello di servizio.

Edit:

Si noti che quando si utilizza esagonale Architecture (che è una buona misura per DDD), il livello di servizio non è lo stesso del livello di persistenza. Il livello di servizio utilizza il livello di persistenza per caricare e salvare gli aggregati nel DB.

+0

L'infrastruttura del livello applicazione è indipendente? Quindi il framework REST è il primo client del livello applicazione? – danfromisrael

+0

@danfromisrael vedere la mia risposta aggiornata – theDmi

+0

Grazie a @theDmi per la risposta. Sono pienamente d'accordo con l'approccio che hai descritto, ma ho una domanda. Diciamo che abbiamo un metodo GET che restituisce un elenco di oggetti, ogni oggetto ha una colonna di stato. Ora dobbiamo creare un nuovo metodo GET che restituisca un elenco di stati unici insieme al numero di elementi con questo stato. A tale scopo, creiamo una nuova classe DTO con due attributi: 'Stato stringa' e' Numero lungo '. In quale strato questa classe dovrebbe essere definita? Applicazione, giusto? Se il repository, che è basato su DDD, restituisce istanze delle classi del livello applicazione? –

Problemi correlati