Lingua Ubiquitous e livello di maturità nell'API REST?

Question

Lingua Ubiquitous e livello di maturità nell'API REST?

#1 da (4 voti)
#2 da (0 voti)

4

Secondo il modello di maturità di Richardson ci sono diversi livelli di maturità nell'approccio REST. link

Dal momento che DDD utilizza un linguaggio ubiquitario, mi chiedo quale livello di maturità è consigliato, se un'API REST è un livello di presentazione del mio progetto DDD?

L'uso di un linguaggio ubiquitario potrebbe consentire ad alcuni nomi interessanti all'interno di un contesto limitato, ma quando lo si espone al mondo esterno, come potrebbe essere tradotto in un adeguato livello di maturità?

design domain-driven-design design-patterns rest domain-model

posta Dario Granich 03.05.2016 - 12:11

fonte

2 risposte

Leggi altre domande sui tag design domain-driven-design design-patterns rest domain-model

È una buona idea non incorporare certe relazioni uno a uno in un database Mongo? Ramo di funzionalità che non è mai stato sviluppato

score 4 · Answer 1

I livelli di maturità REST e DDD sono problemi ortogonali.

Il tuo linguaggio onnipresente non si preoccupa se è riflesso in profondità nel carico utile di un messaggio SOAP, in un URI di risorsa o in un tipo di contenuto specifico del dominio, purché rimanga pervasivo e coerente nel suo Contesto Limitato.

Se il tuo Contesto Limitato include sia le parti client che quelle server, HTTP ti ostacolerà inevitabilmente, interrompendo la continuità semantica tra il client e il Servizio Applicazione. Se aderisci alla Prima legge degli oggetti distribuiti , non c'è modo di aggirarla. Durante la lettura o la programmazione del codice client, non sarà mai così fluido e facilmente individuabile come la chiamata di un metodo chiamato dopo un concetto di dominio su un oggetto chiamato dopo un concetto di dominio. Ci sarà sempre un disadattamento di impedenza tra i comandi del protocollo HTTP ei verbi o comandi di dominio.

Se il BC termina a livello di applicazione e / o agisce come fornitore o servizio di host aperto su altri sistemi, HATEOAS potrebbe fornire una lingua pubblicata più chiaramente espressa e rilevabile (sotto forma di un Domain Application Protocol) rispetto agli altri livelli, con meno sforzo. Ma le implementazioni di livello 0, 1 o 2 ben documentate possono rimanere perfettamente valide in base ad altri criteri contestuali.

score 0 · Answer 2

Se consideriamo che stai facendo lato server e il tuo "client" lato client. Un DDD dovrebbe essere almeno un approccio di HATEOAS ma probabilmente anche di più:

aggiunta di un nuovo metodo HTTP pertinente al dominio. Esempio DELETE potrebbe essere adatto per una disabilitazione e una riattivazione potrebbe avere un verbo RESTAURE. (Sì, questo può essere fatto con PUT ma questo è meno guidato dal dominio).
URL completamente leggibile dall'uomo che potrebbe entrare in conflitto con il linguaggio ubiquitario definito con il client. Ad esempio nel livello 1 l'URI persone / 1 / indirizzo darà l'indirizzo delle persone con id uno. Ma la lingua onnipresente potrebbe aspettarsi di avere qualcosa come persone / indirizzo / id = 1.
Usa un altro formato che quello indicato nel link. Qualcosa che seguirebbe la lingua onnipresente invece di XML.

Ma se stai facendo il lato client, il tuo servizio "REST" può essere al livello 0 (anche se non sarebbe un servizio REST in base al link) poiché sarà nascosto dal client.

Questo è solo un pensiero approssimativo delle possibilità.