Progettazione basata su domini: come gestire modelli complessi con molti campi dati?

Question

Beh, sto cercando di applicare i principi di progettazione basati su domini per la mia applicazione, con un modello di dominio ricco che contiene sia campi di dati che logiche di business. Ho letto molti libri su DDD, ma sembra che i loro modelli di dominio (chiamati entità) siano molto semplici. Diventa un problema quando ho un modello di dominio con 10-15 campi di dati, come quello qui sotto:

class Job extends DomainModel{ 

    protected int id; 
    protected User employer; 
    protected string position; 
    protected string industry; 
    protected string requirements;  
    protected string responsibilities;  
    protected string benefits; 
    protected int vacancy; 
    protected Money salary; 
    protected DateTime datePosted; 
    protected DateTime dateStarting; 
    protected Interval duration; 
    protected String status; 
    protected float rating; 

    //business logic below 
} 

Come potete vedere, questo modello di dominio contiene un sacco di campi di dati, e tutti loro sono importanti e non può essere spogliato. So che un buon modello di dominio ricco non dovrebbe contenere metodi setter, ma piuttosto passare i suoi dati al costruttore e mutare stati usando la logica di business. Tuttavia, per il modello di dominio sopra riportato, non posso passare tutto al costruttore, poiché porterà a 15+ parametri nel metodo del costruttore. Un metodo non dovrebbe contenere più di 6-7 parametri, non pensi?

Quindi, cosa posso fare per gestire un modello di dominio con molti campi dati? Dovrei provare a scomporlo? Se é cosi, come? O forse, dovrei semplicemente usare una classe Builder o una riflessione per inizializzare le sue proprietà al momento dell'istanza, quindi non inquinerò il costruttore con così tanti argomenti? Qualcuno può dare qualche consiglio? Grazie.

Answer 1

Quello che ti è mancato è il concetto di un oggetto valore. Gli oggetti valore sono oggetti piccoli e immutabili con significato nel rispettivo dominio.

non so le specifiche del proprio dominio, ma guardando il tuo Job entità, ci potrebbe essere un oggetto di valore JobDescription che assomiglia a questo:

class JobDescription { 
    public JobDescription(string position, string requirements, string responsibilities) { 
     Position = position; 
     Requirements = requirements; 
     Responsibilities = responsibilities; 
    } 

    public string Position {get;} 
    public string Requirements {get;} 
    public string Responsibilities {get;} 
} 

Si tratta di codice C#, ma penso l'idea dovrebbe essere chiara indipendentemente dalla lingua che stai usando.

L'idea di base è i valori di gruppo in un modo che ha senso nel rispettivo dominio. Ciò significa ovviamente che gli oggetti valore possono contenere anche altri oggetti valore.

È inoltre necessario assicurarsi che gli oggetti valore vengano confrontati per valore anziché per riferimento, ad es. implementando IEquatable<T> in C#.

Se si rifatta il codice con questo approccio, si ottengono meno campi sulla propria entità, quindi l'utilizzo dell'iniezione del costruttore (che è altamente raccomandato) diventa nuovamente possibile.

---

Ulteriori note per quanto riguarda il codice di esempio che non sono direttamente collegati alla domanda:

• Il modello dominio è il tutto, un un'entità è parte di essa. Quindi la tua classe base dovrebbe essere chiamata Entity e non DomainModel.

• È necessario creare i campi della classe private e fornire gli accessor protected dove richiesto per mantenere l'incapsulamento.

Answer 2

C'è un sacco succedendo nel vostro lavoro modello di dominio oggetto - sembra mescolare un numero enorme di problemi, e (almeno per me) suggerisce una serie di contesti limitati, alcuni dei quali sono facili da discernere per fare un esempio.

1. Remunerazione (a pagamento, benefici)
2. posizione organizzativa (linea di segnalazione)
3. persona spec (abilità)
4. specifiche di lavoro (responsabilità)
5. ecc

Quando si considera le cose che interagiscono con il tuo modello 'Lavoro', ci sono quelle che hanno bisogno di ispezionare o mutare ENTRAMBI la proprietà Salary e la proprietà Industry, per esame pio?

Senza conoscere le sfumature complete del dominio, lo stipendio si ottiene per mantenere una posizione e l'industria in cui lavori non sono realmente connessi, vero? Non un punto retorico; queste sono le domande che devi rivolgere agli esperti del dominio.

Se NON hanno alcuna interazione, allora avete identificato che queste due cose esistono in due diversi CONTEGGI SOVRAPPOSTI. Il lato Salary non ha bisogno di alcuna interazione con il lato dell'Industria e viceversa, e anche se lo facessero, hanno bisogno di essere tenuti come stati nello stesso processo nello stesso momento?

Pensa al ciclo di vita di come una persona diventa dipendente; una persona si candida per un lavoro. Il lavoro ha una specifica, gamma di salari. La persona frequenta un'intervista. I locatari offrono alla persona la posizione. La persona accetta. La persona ora è un dipendente, non un candidato più. Il nuovo dipendente sta ora accumulando ferie e sussidi e ha una data di inizio ecc.

DDD ci insegna che una singola visione unitaria del mondo raramente serve QUALUNQUE dei problemi in modo corretto. Si prega di esplorare CONTESTI LIMITATI - il vostro software sarà molto più flessibile e flessibile di conseguenza.