Mi sto adoperando per avere l'architettura più gestibile possibile nella mia applicazione, ma non riesco a decidere un modello di dominio adeguato.
Ecco un esempio di modello di dominio per un utente:
public class User // Referred to as the domain model
{
// A model whose properties map exactly to a database table schema
private UserDataModel Model { get; set; } // Posts data back to the database
public string FirstName
{
get
{
return Model.FirstName;
}
set
{
// Validation & Observer logic here
Model.FirstName = value;
}
}
public string LastName
{
get
{
return Model.LastName;
}
set
{
// Validation & Observer logic here
Model.LastName = value;
}
}
public string FullName
{
return $”{FirstName} {LastName}”;
}
public Company Company // Other domain model with a similar design
{
get
{
return Model.Company;
}
set
{
// Validation & Observer logic here
Model.Company = value;
}
}
// List of other domain models with similar designs
public IList<Order> Orders { get; set; }
// …
internal User(UserDataModel user)
{
Model = user;
}
// Domain specific methods here
//(e.g. IsAdmin, CalculateBill, SendPasswordResetEmail, CanPlaceOrder, etc.)
}
In sostanza, le mie preoccupazioni riguardano le migliori pratiche per disporre di una progettazione di un dominio efficace, efficiente e gestibile che consenta un consumo robusto, una strong incapsulabilità e un'elevata estensibilità / manutenibilità o scalabilità. Le domande specifiche sono:
-
Proprietà
a) Se il mio modello di dominio contiene proprietà simili al modello di dati sottostante o proprietà che sono rilevanti solo per il consumo del modello di dominio dell'applicazione (cioè proprietà come FullName, flag booleani come Dirty (aggiornamenti si è verificato), Prototipo (cioè, un nuovo modello fittizio per la creazione da parte del cliente / consumatore)?
b) il modello di dati sottostante deve essere esposto pubblicamente per l'accesso o dovrebbe essere accessibile solo tramite metodi? Dovrebbero essere restituite solo parti del modello dati o l'intero oggetto?
c) il modello di dominio dovrebbe includere oggetti collegati (come l'oggetto Company nell'esempio) o solo il valore pertinente a quell'oggetto collegato (ovvero la proprietà Name dell'oggetto Company invece del intero oggetto)?
d) I setter dovrebbero essere simili a quelli sopra o solo attraverso metodi chiamati sul modello di dominio o metodi privati chiamati nel setter della proprietà (cioè set {SetFirstName (valore);})? (Nota: i setter implementeranno le chiamate del motore di validazione e le chiamate dell'osservatore e le chiamate di servizio, quindi saranno relativamente pesanti)
-
Costruzione
a) Devo affrontare la costruzione di un nuovo modello di dominio dal cliente / consumatore tramite diversi metodi set o semplicemente mappando le proprietà a livello di client / consumatore o tramite uno schema factory / builder?
b) Il mio modello di dominio dovrebbe nascondere completamente la struttura di dati sottostante che rappresenta (ad esempio, appare come se fosse un oggetto che non faceva mai parte di un database)?
c) La convalida deve essere eseguita a livello di costruzione (ovvero quando le proprietà sono impostate) o lasciata al cliente / consumatore chiamando un metodo "IsValid" sul modello di dominio quando appropriato?
-
Validation
a) Gli errori di convalida devono essere memorizzati in una raccolta nel modello di dominio o in un modello di errore separato / classe singleton?
b) La convalida deve essere eseguita a livello di modello di dominio o a livello di modello di dati?
-
Recupero
a) per gli elenchi di oggetti (cioè gli ordini), se l'elenco deve essere privato e accedere tramite un metodo "GetOrder (string orderNo)"? Non sarebbe una violazione del principio di Responsabilità Unica (I.e il metodo è uno pseudo repository / fabbrica) o no?
b) Come si può recuperare un intero elenco senza influire sul modello di dominio contenente o sui modelli di dominio nell'elenco? Dovrebbe essere usato un clone nonostante sia potenzialmente impegnativo in termini di memoria (un utente potrebbe avere migliaia di ordini con i propri modelli di dominio collegati)?
Sto idealmente cercando di evitare lo sviluppo di un design di dominio non gestibile che è un dolore da consumare o testare. Voglio che il modello di dominio sia fluente e amp; il più robusto possibile, permettendogli così di essere letto come prosa al cliente / consumatore e rappresentando il dominio effettivo e non le strutture di dati sottostanti (cioè dovrebbe essere in grado di agire come se stesse da solo senza un back-end).