Separazione del modello di dominio dal modello di dati

1

Sto cercando di capire come separare il modello di dominio dalla modalità di persistenza in modo che i due possano variare in modo indipendente come descritto qui e qui

Comprendo il vantaggio di mappare l'ORM direttamente al modello di dominio, ovvero la velocità di sviluppo. Questo sarebbe il mio approccio normale.

Dire che volevo separare il modello di dominio dal modello di dati. Ho due domande:

1) La mia ricerca mi dice che il limite principale di questo è il rilevamento dei cambiamenti. Come è questo un problema? Vorrei mappare il modello di dominio al modello di dati per mantenere le modifiche - a quel punto NHibernate (il mio ORM) avrebbe trovato le modifiche.

2) Esistono esempi di sistemi o esempi open source che mostrano come separare il modello di dominio dal modello di dati?

Ho letto molte domande qui (e Stackoverflow) simili alle mie, ad es. questo . Tuttavia, nessuno risponde alle mie domande specifiche secondo me.

    
posta w0051977 26.12.2017 - 16:26
fonte

2 risposte

3

Per rispondere a # 1 - quando si separa il modello di dominio dal modello di persistenza, il rilevamento delle modifiche non è un problema. La ragione è che il rilevamento delle modifiche è più una preoccupazione trasversale rispetto a un problema relativo al dominio. La preoccupazione di un modello di dominio non è quella di garantire che le modifiche a se stesso siano tracciate.

Le modifiche che vogliamo monitorare sono in genere quelle che persistono anche noi. IOW, se, nel corso di qualche elaborazione, cambiamo un valore di proprietà e poi lo cambiamo, non ci sono cambiamenti da persistere, il che significa che non ci sono cambiamenti da tracciare. Quindi mi piacerei per il rilevamento delle modifiche come comportamento della persistenza, non del dominio.

A cura: Ecco una nota di Patters, Principles e Practices of Domain-Driven Design :

Don't put dirty flags on domain objects
It might be tempting to put a flag on a domain object to signify that it has changed. The problem with this is that you are clouding the domain model with persistence concerns. Leave all change tracking to the unit of work and the repository.

Per # 2 - Non ho un esempio open source. Ma per cominciare, la separazione tra modelli di dominio e modelli di persistenza significa assicurare che la persistenza sia astratta, magari usando il modello del repository.

Se i modelli di dominio dipendono da un'astrazione del repository "persistente ignorante", come

public interface IRepository<T> where T : class
{
    void Add(T item);
    void Update(T item);
    void Delete(T item);
    void Get(RecordId id);
}

Quindi l'implementazione di quel repository può mappare quel T ae da qualsiasi modello specifico della persistenza e il dominio non saprà mai che il modello di persistenza esiste.

Affinché ciò avvenga, il dominio deve definire la propria interfaccia di repository anziché iniettarne una definita in una libreria di persistenza. Ciò lascia il dominio della persistenza del dominio agnostico e più semplice da testare e solo le implementazioni di quel repository sono a conoscenza dei dettagli della persistenza.

    
risposta data 26.12.2017 - 17:09
fonte
0

Accordo, modello di dominio e archivio persistente dovrebbero essere preoccupazioni diverse. O ancora un ulteriore passo avanti, ci dovrebbe essere NO preoccupazione persistente in OO affatto . Dicendo questo, voglio dire che non dovremmo modellare alcun oggetto in OO per l'archivio dati. Lo schema del repository si adatta molto bene, qualsiasi oggetto proveniente dal repository dovrebbe essere un oggetto dominio. Il modello dati è una struttura tabella / vista in caso di RDBMS e schema (o solo struttura json) di NOSQL.

In RDBMS, ORM svolge un ottimo lavoro nel colmare il divario tra il modello di dominio e il persistente. L'unica cosa che dobbiamo fare attenzione è il file della mappa o le annotazioni (attributi in c #). Inoltre, i moderni ORM (come l'ibernazione) risolvono molto bene il rilevamento delle modifiche, non è necessario fare nulla a livello di oggetto.

Personalmente, suggerirei:

  • Il modello di dati deve essere inserito nell'archivio dati e non presentare perdite nel modello a oggetti;
  • Il modello dati dovrebbe seguire il modello di dominio;

Per la tua seconda domanda, ecco un esempio java di Vaughn Vernon. Gli esempi di Applicazione di pattern e pattern basati su domini di Jimmy Nilsson: con esempi in C # e .NET sono buoni per C # lettori.

    
risposta data 26.12.2017 - 22:08
fonte

Leggi altre domande sui tag