Raggiungere "Persistenza ignoranza" avendo un modello di persistenza separato dal modello di dominio

Penso che forse parte di ciò con cui stai combattendo qui sia che gli ORM sono progettati per sedersi nello stesso punto del progetto in cui il livello di persistenza dovrebbe disaccoppiare lo storage e il modello di dominio. Se vuoi utilizzare un ORM e farlo, l'unica soluzione efficace è spingere l'ORM verso il basso e trattarlo come lo storage sottostante che è esattamente quello che hai concluso correttamente.

However, I did find aspects of the ORM and, even more so, the underlying database leaking through into my domain model, ...

Questo è uno dei miei maggiori problemi con l'ORM pesante. È molto "supponente" e tende ad essere approssimativamente isomorfico alla struttura del database sottostante. Allo stesso tempo, è facile (anche incoraggiato) collegarlo direttamente al modello di dominio che diventa quindi approssimativamente isomorfico alla struttura del database. Puoi combatterlo con configurazioni complesse in molti strumenti ORM, ma penso (dall'esperienza) che sia una cattiva idea dato che probabilmente creerai un sacco di problemi per far sì che l'ORM si comporti come necessario.

Quindi, il risultato finale è essenzialmente un livello aggiuntivo con molti tipi che esistono semplicemente per interfacciarsi tra il livello del dominio e l'ORM. Qui è dove arriva la manutenzione "extra".

Una soluzione alternativa è quella di abbandonare l'ORM e creare un livello di persistenza che mappa direttamente dal livello del dominio a uno o più livelli di persistenza. Nel tipo di lavoro svolto dal mio team, in genere iniziamo con più sistemi / obiettivi di archiviazione che dobbiamo supportare e ci aspettiamo di dover scambiare o accogliere un cambiamento in questi obiettivi nella scala di ogni 1-2 anni. Quindi questo tipo di disaccoppiamento è abbastanza essenziale per noi essere in grado di accogliere anche le modifiche dei requisiti funzionali nel dominio e sì, può essere fatto.

A mio avviso non ne vale la pena. Alla fine degli anni '90 ho lavorato per un'organizzazione no-profit e avevano un'applicazione basata su dbase IV. Non ricordo nemmeno in cosa sia stato scritto il codice dell'app. Pascal? COBOL? Non ricordo. In ogni caso è stato riscritto per la prossima tecnologia, MS Access e VB.

Ogni progetto in cui sono stato coinvolto non ha mai avuto bisogno di estrarre lo strato ORM né il database. Queste non sono le parti del sistema che richiedono molti cambiamenti. Logica di business, front-end: ecco dove tutte le modifiche tendono ad essere.

Non capisco davvero l'ossessione di alcune persone per lo swapping dell'infrastruttura. Non ne vale quasi la pena. Quando inizi a essere limitato dalla tua infrastruttura, sarà probabilmente solo in una piccola parte della tua applicazione per alcuni casi d'uso specifici, e in quello scenario è meglio spostare quelle piccole parti di base in infrastrutture realizzate appositamente per il tuo caso d'uso, e quell'infrastruttura sarà così radicalmente diversa che dovrai comunque riscrivere il tuo modello di dati.