Transizione dal progetto database-first al progetto DDD

Question

Transizione dal progetto database-first al progetto DDD

#1 da (4 voti)

8

Abbiamo un progetto web api c # che è stato creato utilizzando il database-first diversi anni fa. Ora è necessario passare all'architettura DDD per questo stesso progetto. Il motivo principale di ciò è porre l'accento sulla logica di business (che non è cambiata molto) e sul design delle applicazioni in modo che abbia una stanza da espandere con nuove funzionalità. Ovviamente con il codice spaghetti questo non è così facile da fare.

Poiché sappiamo che DDD non è solo un approccio code-first, ma utilizza molti modelli e modelli diversi con il modello di dominio come priorità principale, stiamo cercando alcune risposte che renderebbero questa transizione il più agevole possibile

Possiamo costruire il dominio sopra il modello db esistente? (Dal momento che DDD dovrebbe essere persistenza ignorante, questo dovrebbe essere raggiungibile)
Possiamo creare aggregati da oggetti db esistenti?
Un nuovo progetto partendo da zero (incluso db) sarebbe l'opzione migliore?

Abbiamo trovato l'articolo correlato link ma non menziona costruzione del dominio in base al contesto esistente

design c# domain-driven-design

posta John 24.01.2017 - 23:46

fonte

1 risposta

Leggi altre domande sui tag design c# domain-driven-design

Che cosa significa la licenza di Apache per "Permesso: uso commerciale" La documentazione utente include gli screenshot? [duplicare]

score 4 · Answer 1

Abbiamo fatto qualcosa di molto simile qualche anno fa - prendendo un modello db legacy e provando a sostituirlo con uno nuovo, meglio strutturato, in cui tutto il nuovo codice usa solo il nuovo modello, mentre il vecchio sistema è ancora in uso. Per trasferire questo nel tuo caso, pensa a un nuovo modello di dati progettato da un approccio DDD.

Da questa esperienza ti suggerisco di costruire il nuovo modello in gran parte indipendente da quello vecchio, utilizzando il meccanismo di persistenza di tua scelta e creare un processo ripetibile di migrazione per trasferire il nuovo dati esistenti sulla "vita" nella nuova struttura. Forse avrai anche bisogno di un processo di migrazione inversa (ma le cose sono molto più semplici se puoi organizzare il tuo flusso di dati in modo unidirezionale).

Quindi quello che puoi fare qui non è costruire il dominio "sopra" del db esistente, ma "side-by-side". Ciò consentirà di utilizzare il vecchio database e il codice che si basa su di esso per un periodo più lungo in combinazione con la nuova struttura, che è ciò che in genere è necessario per una transizione graduale. Quindi puoi far crescere le nuove strutture in modo incrementale, creare un nuovo codice su di esso e sostituire le parti più vecchie del sistema passo dopo passo.

Lo svantaggio è che i processi di migrazione possono diventare complessi nel tempo e se non si segue una strategia di sostituzione rigida, si potrebbe finire con un sistema complesso in cui è necessario mantenere metà del lavoro sulle strutture legacy, l'altra metà sulle nuove strutture, oltre ai processi di migrazione stessa. Nel nostro caso, abbiamo sostituito solo alcune delle peggiori strutture del vecchio database e mantenuto tutto ciò che era di qualità accettabile. Dato che c'è una netta separazione tra un "backend" che lavora sulle nuove strutture e un "frontend" che lavora sulle vecchie strutture, per noi andava perfettamente bene. Ma YMMV - devi determinare da solo ciò che funziona per il tuo tipo di sistema.