DDD: come riconciliare un BoundedContext con DTO REST / WebService?

Question

DDD: come riconciliare un BoundedContext con DTO REST / WebService?

#1 da (2 voti)

3

Sto appena iniziando a conoscere DDD e sto cercando di capire in che modo i contesti limitati possono essere riconciliati con le API rivolte al cliente come REST / WebServices che utilizzano DTO.

Ad esempio: il tuo sistema espone la sua API al pubblico con un WebService standard, con operazioni in stile CRUD per oggetti DTO con molti campi definiti tramite un WSDL. Crei un Contesto Limitato per gestire la logica di business del tuo Dominio, usando un modello di dominio "non anemico" - in modo che i tuoi oggetti di dominio non abbiano semplicemente un gruppo di setter e getter - invece hanno metodi definiti usando il vocabolario dal tuo linguaggio ubiquitario . Come si può conciliare la differenza tra il loro DTO del servizio web e il Contesto limitato? Mi sembra che questo potrebbe aggiungere un'enorme quantità di complessità, e mi chiedo se ci sono alcuni modi ben definiti per risolvere questo problema.

domain-driven-design architecture enterprise-architecture

posta Dan Ling 07.05.2014 - 00:03

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design architecture enterprise-architecture

Diagramma di classe UML: come annotare la relazione soggetto-osservatore? Oggetto REST con risorse

score 2 · Accepted Answer

Il modello di dominio espone comandi e query che possono essere utilizzati dall'applicazione. Quindi l'applicazione (in particolare, il "componente anti-corruzione") è responsabile di prendere i DTO e di ri-esprimerli in una forma comprensibile al dominio.

Se stai costruendo la tua applicazione dal modello di dominio, questo è davvero semplice: i tuoi DTO diventano semplicemente rappresentazioni dei comandi stessi e l'API diventa una serie di endpoint che gestiscono tali comandi per conto del client remoto. E il linguaggio onnipresente si diffonde dal modello di dominio fino ai clienti.

Cercando di lavorare verso l'interno del modello di dominio, da un'API che espone tutte le modifiche come un'operazione CRUD ... sì, questo farà schifo fino in fondo. In sostanza, si finisce per scrivere un livello anti corruzione che rivede la modifica proposta e tenta di dedurne l'intento dell'operazione nel client. Cattive notizie.

La buona notizia: se stai seguendo i consigli di Greg Young su quando per usare DDD (ovvero: nelle parti della tua azienda in cui hai un vantaggio competitivo), allora c'è un'enorme quantità di leva - il valore di migliorare il processo potrebbe essere abbastanza alto da compensare il costo della deprecazione dell'API CRUD.

Cavalli per i corsi.