In Domain-Driven Design, puoi utilizzare le entità di dominio nell'interfaccia utente?

Question

In molti progetti DDD principali, in particolare in stile MVC, vedo l'interfaccia utente che utilizza oggetti di visualizzazione che rispecchiano le entità di dominio, anziché utilizzare direttamente tali oggetti di dominio. Questo stile è ovviamente per il disaccoppiamento e la separazione delle preoccupazioni, e personalmente preferisco questo stile.

Ma quello di cui non sono sicuro, è se questo è un principio rigoroso del DDD, o se questo è più semplicemente l'interpretazione di diversi sviluppatori di esso.

È possibile utilizzare gli oggetti del dominio direttamente nell'interfaccia utente e continuare a seguire la metodologia DDD in tale atto?

Oppure è una pratica DDD utilizzare sempre gli oggetti di visualizzazione?

Nota: mentre menziono MVC, mi interessa sapere se gli oggetti di visualizzazione devono essere utilizzati in quasi tutti i pattern UI compatibili DDD in un progetto DDD.

Answer 1

DDD è un modo di pensare mentre si progetta un software che inizia con la modellazione del dominio. Come il webpage lo mette:

Domain-Driven Design non è una tecnologia o di una metodologia. È un modo di pensare e un insieme di priorità , volte ad accelerare i progetti software che devono gestire con domini complicati.

Una cosa che segue naturalmente questo schema di progettazione è un'architettura a strati. Come si è detto in DDD Pattern Summaries

partizione un programma complesso in STRATI. Sviluppare un design all'interno di ogni LAYER che sia coesivo e che dipenda solo dagli strati sottostanti. Seguire i modelli di architettura standard per fornire un accoppiamento libero ai livelli sopra. Concentrare tutto il codice relativo al modello di dominio in un livello e isolarlo dall'interfaccia utente , dall'applicazione e dal codice dell'infrastruttura . Gli oggetti dominio , esenti dalla responsabilità di che si visualizzano, memorizzazione di attività, memorizzazione di attività e così via, possono essere concentrati su che esprime il modello di dominio.Questo consente a un modello di evolversi di essere ricco sufficiente e abbastanza chiaro per acquisire le conoscenze aziendali essenziali e mettere a funzionare.

Se è necessario disporre di oggetti di visualizzazione per farlo? Questo è solo un modo per implementarlo, ma potrebbe anche non essere il migliore per fornire un accoppiamento lento. Come per un esempio: forse il livello di visualizzazione è solo un browser e file xlt per visualizzare i file xml emessi dal livello aziendale? Se qualcuno ha esempi più adatti, per favore aggiungili. Il mio punto è che DDD pone l'accento su un'architettura a strati, ma non lo limita a una possibile soluzione.

Answer 2

Se si sta eseguendo un pattern MVC, è necessario visualizzare gli oggetti; il DDD è solo il tuo modello. Ciò non significa che l'utente deve utilizzare utilizzare sempre MVC; un DDD può essere costruito, ad esempio, come un simulatore, in cui tutto ciò che si guarda sono i messaggi di log emessi. Ma in MVC dovresti davvero avere oggetti di visualizzazione separati.

Ora, chiediti perché sarebbe? La risposta è che la vista può essere modificata, anche se il modello di business non è. Il modello DDD dovrebbe esprimere, nei termini del business, ciò che è essenziale per il business.

Answer 3

All'interno di un progetto MVC si ottiene in genere un mapping dal repository -> Modelli di dominio e quindi da Modelli di dominio -> Visualizza modelli. Tuttavia, i modelli di vista contengono spesso oggetti di dominio.

Answer 4

La risposta è abbastanza semplice:

• Gli oggetti di dominio hanno dominio orientata design e metodi.
• Gli oggetti vista hanno un design e metodi orientati alla vista/controllo.

Se è possibile utilizzare gli oggetti dominio nella vista, potrebbero non essere abbastanza orientati al dominio.

Answer 5

Non ho davvero iniziato a capire perché o come dovresti disgiungere il modello di dominio dai problemi di presentazione fino a quando ho iniziato a seguire il lavoro di Greg Young e Udi Dahan (via Martin Fowler).

Hanno insegnato un principio noto come Command and Query Responsibility Segregation (CQRS).

La mia interpretazione di CQRS è che ci sono due serie di responsabilità che possono tirare un modello di dominio in direzioni diverse, risultando in un modello che fa un lavoro mediocre di entrambi. Le due responsabilità sono i comandi (cioè il comportamento che causerebbe una scrittura nel database) e le query (cioè la lettura dal database al fine di recuperare i dati per il consumo dell'interfaccia utente). Un esempio potrebbe essere l'aggiunta di getter e setter alle entità per supportare l'associazione dati nell'interfaccia utente. Se il tuo modello ha getter e setter, probabilmente farà uno scarso lavoro di modellazione delle modifiche dello stato che devono avvenire in modo logico o incapsulante. Inoltre, non sarà in grado di modellare il contesto aziendale dei cambiamenti di stato (consultare Event Sourcing).

In termini DDD, è possibile affermare che il modello di dominio e il modello di presentazione sono in genere in contesti separati.

La soluzione come prescritto da CQRS è quella di creare un modello per i comandi e un altro per le query. Se il modello corrente dispone di metodi per modificare lo stato (ad esempio il comportamento nel modello) e getter che espongono lo stato a un'interfaccia utente per l'associazione dati, si dovranno rifattorizzare queste due responsabilità in modelli separati per comandi e query. Il modello di query non verrà mappato alle entità di dominio, ma direttamente al database. Se il tuo database non acquisisce lo stato derivato dal tuo modello di dominio, controlla un pattern chiamato Eager Read Derivation.

Se il sistema è semplicemente CRUD e non ha un comportamento, provare un sistema di ponteggio che può essere costruito automaticamente fuori del vostro schema del database, come ASP.NET Dynamic Data

Answer 6

oggetti di dominio sono in realtà la logica interna dentro la tua strato di logica aziendale. Non dovrebbero essere esposti direttamente ai tuoi clienti (livello dell'interfaccia utente). Invece, incapsula l'uso del tuo modello di dominio in servizi applicativi. I servizi applicativi possono utilizzare DTO e/o oggetti di comando leggeri per trasmettere dati e intenti tra il client e il modello di dominio.