Il livello del dominio dovrebbe dipendere da NHibernate?

Question

Il livello del dominio dovrebbe dipendere da NHibernate?

#1 da (5 voti)
#2 da (4 voti)
#3 da (-2 voti)

3

Vedi il codice qui sotto:

public interface IUnitOfWorkWrite <TSession> : IDisposable
    {
        TSession Session { get; }
        void Commit();
        void Rollback();
        ITransaction BeginTransaction();
    }
}

Questa interfaccia è contenuta nel livello dominio. Il livello di servizio fornisce un'implementazione. Pertanto, il livello del dominio non dipende da nient'altro che da NHibernate, ad esempio NHibernate deve essere installato per Session e ITransaction.

Il livello del dominio dovrebbe dipendere da NHibernate in questo scenario?

c# domain-driven-design nhibernate

posta w0051977 18.10.2017 - 14:37

fonte

3 risposte

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

L'ID dovrebbe essere indicato nell'URL se già protetto con ID JWT? Gestione di una base di codice per più client, con il proprio codice personalizzato

score 5 · Answer 1

Should the domain layer be dependent on NHibernate in this scenario?

Da una prospettiva purista: no non dovrebbe. Il livello del dominio non dovrebbe comportare una serie di dipendenze dalla soluzione di persistenza. "UnitOfWork" e "Transazione" non fanno parte del linguaggio ubiquitario della maggior parte dei domini aziendali.

Dal punto di vista della cipolla: la tua dipendenza sta indicando la strada sbagliata. Invece di aggiungere una dipendenza da NHibernate, puoi inserire un'interfaccia di fornitore di servizi agnostico nel tuo modulo e quindi passare un'implementazione di NHibernate dell'interfaccia agnostica alle porte che ne hanno bisogno.

In pratica: dubito che la polizia DDD verrà a cercarti.

Domain Services can access the database

Non proprio giusto. Implementazioni di Domain Services possono accedere al database. L'interfaccia , utilizzata dal modello di dominio, esprime semplicemente il servizio nella lingua del dominio. L'implementazione si baserà su altri servizi applicativi e di infrastruttura, ovvero su altri fornitori di servizi di interfacce che definisce e sulle sue tartarughe.

La cosa che effettivamente parla di NHibernate probabilmente sarà un servizio di infrastruttura.

In altre parole, probabilmente la tua composizione root avrà un aspetto simile a

NHibernateThing nhibernate = ...
DomainServiceImpl.Adapter infrastructure = InfrastructureService.using(nhibernate)
DomainService service = DomainServiceImpl.using(infrastructure)

dove si collega ciascun adattatore alla porta appropriata a sua volta.

Rileggi Parnas ; a un livello fondamentale, NHibernate è il risultato di una decisione e si desidera che i limiti del modulo siano in grado di separare i pezzi che dipendono da tale decisione dai pezzi che non lo fanno. Ciò rende più facile cambiare quando arriva il momento.

Ma - dovresti bilanciare questo contro il rischio di cambiamento; se NHibernate farà sempre parte della tua soluzione, non dovresti investire nel disaccoppiarlo dal tuo dominio.

score 4 · Answer 2

Il tuo livello di dominio è il punto in cui aggiungi valore al software che stai creando. NHibernate è un mezzo per un fine. Legare il valore del tuo software a una soluzione che non ha molta importanza è un errore strategico. Ciò che intendo è che chiunque stia pagando per questo o chiunque stia usando questo in realtà non (o non dovrebbe) preoccuparsi di come leggi e scrivi dati.

Il problema arriva quando improvvisamente hai bisogno di allontanarti da NHibernate. Supponiamo che tu sappia prima di rilasciare che NHibernate ha un difetto di sicurezza fondamentale e nessuna correzione è in vista? Se hai accoppiato il tuo valore (il livello del dominio) a questo pacchetto, sei fregato. O, più probabilmente, viene fuori un altro strumento che preferiresti usare ma il costo di commutazione è troppo alto per giustificare.

Come menziona CatWhisperer nei commenti sottostanti, ci sono anche altri motivi pratici per non farlo. Per uno può complicare la derisione e altri tipi di test. Significa anche che si sta approssimativamente legando il proprio modello di dominio a un modello di persistenza. Ciò rende il software che stai creando meno riusabile in quanto impedisce di utilizzare il tuo modello di dominio con altri tipi di fonti di dati. Ad esempio, supponiamo che qualcuno voglia eseguire una simulazione Monte Carlo usando il tuo modello di dominio. Non sto dicendo che è necessariamente impossibile farlo con NHibernate, ma aggiungerà molta complessità.

Lavoro con il software di un fornitore che ha realizzato un'importante parte della loro implementazione utilizzando una funzione proprietaria di una piattaforma costosa. Al momento in cui lo hanno deciso, era normale eseguire il software in questo modo, così hanno pensato che fosse soddisfacente. Ora questa piattaforma rappresenta una parte significativa del costo di gestione del software: un enorme errore strategico. Qualunque sia il tempo che pensano di aver salvato utilizzando questa funzione, è completamente sopraffatto dalla realtà che nessuno dei loro clienti vuole pagare per questa costosa piattaforma. Rende il loro software più costoso e sostanzialmente riduce i loro profitti perché non vedono un centesimo di quel costo aggiuntivo. Anche il costo per rimuovere la dipendenza è elevato. Questo errore completamente evitabile ti costerà molti milioni di dollari di entrate.

score -2 · Answer 3

Se il tuo livello di dominio è il punto in cui accedi ai tuoi dati tramite NHibernate, allora sì, dovrebbe dipendere da esso. Se stai chiamando ad un altro livello per gestire l'accesso, allora l'astrazione perde e hai dettagli sull'accesso ai dati in luoghi dove non dovrebbe essere.

I livelli che non accedono ai dati dovrebbero dipendere solo da oggetti che rappresentano i dati e non sapere nulla su come essi sono accessibili. In caso contrario, non stai seguendo il principio di apertura / chiusura in quanto hai oggetti con più motivi per cambiare.