Gli oggetti dominio / modello attribuiscono buone pratiche

Dipende. L'avvio con attributi solo persistenti è l'approccio più tipico e l'aggiunta di attributi non persistenti dovrebbe in genere rappresentare un'eccezione. Ma una tale decisione è sempre un compromesso, e dove si disegna la linea dipende dalle responsabilità che si assegnano a quell'oggetto. Alcuni motivi tipici per l'aggiunta di attributi non persistenti:

• ne hai bisogno per un'operazione che appartiene chiaramente all'oggetto e tenerli all'interno dell'oggetto risulta molto più semplice rispetto all'utilizzo di un secondo oggetto (nota che un secondo oggetto ha bisogno della sua durata per essere gestito separatamente)

• vedi un'opportunità per mantenere l'API del tuo modello di dominio il più semplice possibile

• hai bisogno di un'opzione per memorizzare questa informazione aggiuntiva, temporanea senza modificare troppo codice in un programma esistente, e sei sicuro che usare una classe diversa o oggetti avrà un impatto troppo grande

• motivi di rendimento (si presume che si abbia un collo di bottiglia delle prestazioni reale e misurabile, che può essere risolto più facilmente inserendo nella cache alcuni dati nell'oggetto)

Hai ragione quando dici che il modello non dovrebbe contenere nulla fuori tema e dovrebbe contenere i suoi dati "strettamente". Tuttavia, questo non ha nulla a che fare con la persistenza o con i modelli specifici dell'implementazione.

Il modello di dominio è ciò che useresti per spiegare il tuo sistema a qualcuno che non ha idea del tuo linguaggio di programmazione o dei tuoi framework. Nel migliore dei casi, puoi usarlo per comunicare con i non programmatori.

Sulla base del modello di dominio puoi sviluppare il tuo modello di dati che, a sua volta, descrive cosa stai persistendo e come. Non includeresti qui dati transitivi / calcolati, ma probabilmente ID specifici per database e cose del genere.

Si noti che questi due sono solo la base analitica per il modello / diagramma di classe. Le classi che hai possono, ma non necessariamente devono riflettere tutto dagli altri due modelli.

Sembra che tu sia. Se i metadati per l'oggetto del modello non vengono mantenuti, suppongo che potresti avvolgere l'oggetto del modello in un altro oggetto che contiene i metadati per ridurre la confusione su cosa è e cosa non fa parte del modello.

Un modo per farlo potrebbe sembrare qualcosa di simile:

//Model that will actually be persisted
class UserProfile
{
   String name;
   String address;
   String age;
   ...
}

//"enhanced" version of the model.
class ApplicationUserProfile
{
    UserProfile userProfile;
    String webSessionID;
    Timestamp lastActiveTS;
    bool useABCServer;
    int someThresholdValue;
    //other related metadata fields that aren't persisted
 }

O se vuoi mantenere le cose un po 'più organizzate:

//Model that will actually be persisted
class UserProfile
{
   String name;
   String address;
   String age;
   ...
}

class UserProfileMetadata //extends Metadata //(if you have some common metadata class)
{
    String webSessionID;
    Timestamp lastActiveTS;
    bool useABCServer;
    int someThresholdValue;
    ...
    //other related metadata fields that aren't persisted
}

//"enhanced" version of the model.
class ApplicationUserProfile
{
    UserProfile userProfile;
    UserProfileMetadata metadata;
}