Dove si trova l'attività / servizio di importazione dei dati in DDD?

0

Attualmente sto cercando di creare la mia prima soluzione seguendo i principi del DDD. Fino a poco tempo fa tutto era più o meno chiaro, ma ora ho un compito di importare i dati di configurazione per la mia applicazione e non sono sicuro di quale sarebbe il posto migliore per adattare una simile funzionalità ...

Ho un'applicazione di analisi delle vendite e in alcuni momenti è necessario rinnovare i dati dei listini prezzi (aggiungere nuovi prodotti di eliminazione o aggiornare i prezzi). Quindi in una operazione vorrei importare i dati dei listini prezzi per tutti i prodotti.

Suppongo che potrebbe essere trattato come Price list renewal bounded context Potrebbe avere un aggregato PriceListItem e potrebbe avere un DomainService PriceListRenewalService , ma questo sembra essere un modello anemico (perché questo contesto limitato riguarda solo l'importazione dei dati - quindi risulta essere semplice CRUD).

Domanda

Quale sarebbe il modo corretto di modellare un tale servizio (sottodominio) e quale sarebbe un posto valido (secondo DDD) per tale servizio (Quale strato? Dovrebbe avere un Contesto Limitato o sarebbe ok che tale il servizio funziona direttamente con il database, dal momento che è solo un CRUD?)

    
posta Prokurors 24.10.2016 - 00:19
fonte

2 risposte

5

Direi che il tuo requisito non ha nulla a che fare con DDD. DDD riguarda la risoluzione di complesse regole aziendali in domini aziendali complessi. Non ci sono regole aziendali nel requisito che stai tentando di implementare.

Nel contesto di DDD, i tuoi requisiti faranno parte del livello Application Services e non faranno parte di nessuno dei contesti limitati nel livello del dominio. Pertanto, non dovrebbero applicarsi regole o pratiche del DDD. Quindi considerarlo come un contesto limitato non ha senso.

    
risposta data 24.10.2016 - 12:01
fonte
2

Non ho abbastanza punti per commentare sopra, quindi devo commentare qui.

Suggerirei che il processo non sia necessariamente CRUD se ci sono altre regole di dominio, convalida ed eventi che devono essere considerati durante l'importazione / l'aggiornamento degli articoli del listino prezzi.

Sono finito qui perché sto anche cercando di determinare dove nel mio modello dovrebbe verificarsi un'importazione di dati dei clienti. Passerò attraverso i miei aggregati DDD per importare questi dati, poiché i miei aggregati garantiscono l'integrità del sistema, ovvero assicurando che le proprietà richieste siano impostate e che vengano generati eventuali eventi di dominio. Se dovessi aggirare gli aggregati DDD ed eseguire un CRUD di base sullo stato persistente degli Aggregati, ad esempio, potrei introdurre incongruenze nel sistema.

Potresti anche affrontare questo problema se aggiorni direttamente i dati del listino prezzi, senza passare attraverso i tuoi aggregati. Ad esempio, il tuo PriceListItem ha richiesto campi come valuta, valore, exchangeRateApplied. Che cosa accadrebbe se importassi dei dati privi di valuta o il valore non rientri nei limiti minimo / massimo per il tuo dominio? Inoltre, se hai convalidato i dati nella tua routine di importazione, ora hai 2 set di convalida da mantenere, se il tuo dominio richiede modifiche per adattarsi ai cambiamenti nel business.

Allo stato attuale la mia considerazione al momento è quella di creare un servizio di importazione (WCF), che preleva i record da una coda basata su file system, e chiama i miei gestori di comandi CQRS per elaborare i dati importati.

In questo modo tutta l'interazione avviene attraverso gli aggregati, tramite il mio CQRS, garantendo che i dati definitivi siano coerenti e il sistema sia sempre in uno stato valido.

    
risposta data 15.12.2016 - 15:41
fonte

Leggi altre domande sui tag