Il DDD ha senso per le app che presentano per lo più dati?

4

Sono responsabile della progettazione di un front-end di dashboard e manipolazione dei dati per un database delle transazioni di vendita e non sono abbastanza sicuro del tipo di architettura da utilizzare. Il database è popolato da un sistema ETL esterno.

La funzionalità richiesta per la mia app è molto semplice; deve visualizzare alcuni avvisi di condizioni di eccezione rilevati nel database, presentare alcuni grafici e tabelle e alcune operazioni CRUD di base su alcune tabelle. C'è molto poco comportamento richiesto; l'azienda utilizzerà l'app per scoprire cose, piuttosto che fare cose.

Data questa mancanza di comportamento, ha senso un approccio DDD? Il mio pensiero attuale è di creare viste del database per incapsulare le query di cui la mia app avrà bisogno, avvolgere queste viste con un ORM e chiedere al controller web di interrogare il livello del repository per ottenere un oggetto ORM con i dati di cui ha bisogno. Questo oggetto ORM sarebbe quindi passato al livello di presentazione.

Questo naturalmente crea un strong accoppiamento tra il database, il framework ORM, il livello di presentazione e la mia logica. Una ragionevole quantità di logica ci sarebbe finire nelle viste del database.

Posso far funzionare un approccio DDD per questo tipo di app, oppure esiste un modo più adatto per farlo?

    
posta KJ Tsanaktsidis 15.02.2014 - 04:57
fonte

2 risposte

4

Se c'è poco comportamento un approccio DDD può essere eccessivo, la sua applicazione è totalmente incentrata sui dati e con poca logica probabilmente la soluzione accoppiata può essere una buona decisione. Non so quale tecnologia stai pensando di usare, per un sistema come quello probabilmente sceglierò un framework come rails, grails o django con un pattern ActiveRecord.

Il peggio con questo sistema accoppiato è quando si finisce inconsciamente con un sistema del genere, ma se prendi decisioni consapevoli basate sulla tua conoscenza del problema, cose come DDD o ORM sono solo strumenti nella tua cassetta degli attrezzi e scegli su quello giusto per il progetto a portata di mano.

    
risposta data 15.02.2014 - 11:46
fonte
1

Given this lack of behaviour, does a DDD approach make sense?

Il problema è che stai cercando di risolvere parte del core del business? Trovi un vantaggio competitivo qui?

Se in realtà è "solo uno strumento di query", quindi no. Se mantenere la qualità e l'integrità dei dati non è fondamentale per il successo, allora no.

DDD è un martello troppo costoso per piccoli guadagni incrementali.

    
risposta data 01.02.2016 - 17:41
fonte