È possibile eseguire l'interfaccia DDD e REST e la mappatura della lingua?

Question

REST ha un vincolo di interfaccia uniforme che è il seguente in un formato basato su opinioni molto compresso.

• è necessario utilizzare standard come HTTP, URI, MIME, ecc ...
• Devi utilizzare i collegamenti ipertestuali.
• È necessario utilizzare i vocabri RDF per annotare i dati e collegamenti ipertestuali con la semantica.
• Si fa tutto questo per disaccoppiare il client dai dettagli di implementazione del servizio.

DDD con CQRS (o senza esso) è molto simile per quanto ho capito.

• Con CQRS si definisce un'interfaccia per interagire con il modello di dominio. Questa interfaccia consiste di comandi e classi di query.
• In DDD si definiscono eventi di dominio per disaccoppiare il modello di dominio dai dettagli di persistenza.
• Con DDD hai un linguaggio onnipresente per contesto limitato che esprime la semantica.
• Si fa tutto questo per disaccoppiare completamente il modello di dominio dal mondo esterno.

E 'possibile mappare l'interfaccia uniforme REST all'interfaccia di dominio definita da comandi e query ed eventi di dominio? (Quindi il codice di servizio REST verrebbe generato automaticamente.)

È possibile mappare la semantica dei dati collegati alle lingue ubiquitarie? (Quindi non è necessario definire termini molto simili, basta trovare e riutilizzare i vocab esistenti.)

Si prega di aggiungere un esempio di mappatura molto semplice alla risposta, perché sì o perché no!

Answer 1

non credo che questo è possibile. C'è un termine che credo descriva questo problema, si chiama ontology alignment.

In questo caso avere avere almeno 3 ontologie:

• lingua onnipresente (UL) del modello di dominio
• il vocab specifica applicazione (ASO) del servizio REST
• il Linked Open vocabs dati (Lodo), che il vocabolario specifico applicazione utilizza

Così abbiamo almeno 2 allineamenti:

• UL: allineamento ASO
• l'ASO: allineamento LODO

Il nostro problema è legato alla UL: allineamento ASO, quindi parliamo di queste ontologie.

L'UL è orientato agli oggetti, perché stiamo parlando di DDD e modello di dominio. Quindi la maggior parte degli oggetti di dominio entities, value objects sono oggetti reali e non strutture di dati. La parte non orientata agli oggetti di esso sono le DTO come command+domainEvent, query+result e error sull'interfaccia del modello di dominio.

Al contrario l'ASO è strettamente procedurale, manipoliamo le risorse (strutture dati) utilizzando un insieme di metodi standard (procedure) su di esse.

Quindi, dal mio aspetto stiamo parlando di 2 cose molto diverse e abbiamo ottenuto le seguenti opzioni:

• rendere l'ASO più orientato agli oggetti -> RPC
• rendono l'UL meno orientato agli oggetti -> anemico dominio del modello

Quindi, dal mio punto di vista, possiamo fare le seguenti cose:

• possiamo mappare automaticamente le entità alle risorse e i comandi alle operazioni da CRUD, ad esempio lo HydraBundle fa questo con record attivi (possiamo fare lo stesso con DDD e senza CQRS)

• possiamo mappare manualmente i comandi alle operazioni da un complesso modello di dominio

  • l'operazione POST transaction {...} può risultare un SendMoneyCommand{...}
  • l'operazione GET orders/123/total può risultare un OrderTotalQuery{...}

• non possiamo mappare le entità alle risorse da un modello di dominio complesso, perché dobbiamo definire nuove risorse per descrivere un nuovo servizio o un nuovo metodo di entità, ad esempio

  • l'operazione POST transaction {...} può risultare account.sendMoney(anotherAccount, ...)
  • l'operazione GET orders/123/total può risultare in una query SQL su un database di lettura senza mai toccare una singola entità

penso che non è possibile fare questo tipo di ontologia allineamento scommessa ween DDD + CQRS e REST, ma non sono un esperto di questo argomento. Quello che penso che possiamo fare è creare un vocabolario specifico per l'applicazione con classi di risorse, proprietà e operazioni e mappare le operazioni ai comandi/query e le proprietà alle proprietà comando/query.

Answer 2

Hai posto alcune domande interessanti qui.

Per iniziare con non abbastanza d'accordo con

Con DDD si definiscono gli eventi di dominio per disaccoppiare il modello di dominio dai dettagli di persistenza.

Penso che potrebbe essere fonte di confusione Event Sourcing ES con DDD, ES può essere utilizzato con DDD ma la sua molto opzionale in realtà si dovrebbe dare un sacco di pensiero prima di scegliere come vostro meccanismo di persistenza.

Ora, alla fine della tua domanda, se REST e DDD vanno d'accordo se sì come?

La mia opinione, sì, vanno d'accordo, ma generalmente non si vuole esporre il proprio modello di dominio tramite un'interfaccia REST, si vuole costruire un'astrazione su di esso e quindi esporlo.

È possibile fare riferimento a questa risposta here, per ulteriori dettagli.

Tuttavia non posso raccomandare abbastanza il libro Implementing Domain-Driven Design, capitolo 14 Applicazione si occupa della vostra preoccupazione in misura equo.

Non avrei potuto spiegare più a fondo di quanto il libro e, quindi, si riferisce lì :)