Di solito la logica di dominio dovrebbe essere contenuta nell'entità di dominio, piuttosto che essere inserita in classi esterne specializzate chiamate dall'entità.
Questo è buono per impedire che qualcuno arrivi più tardi, cambia la classe con la logica del dominio e influenza, senza saperlo, l'entità del dominio.
Esempio
Human {
private birth_date;
public calculateZodiac();
public calculateBadLuck();
}
I metodi si basano su birth_date
e incapsulano la logica del dominio dell'entità.
Ma che succede se ..
in un contesto specifico ho bisogno di risparmiare risorse e I non può permettersi di creare un'istanza dell'entità di dominio ma, solo conoscendo la data di nascita, voglio ancora essere in grado di calcolare il zodiaco e sfortuna?
Soluzioni
Logica di dominio in classe esterna
Potrei avere la logica in una classe Zodiac, che ottiene tutti i dati necessari (in questo caso: una data) e restituisce i miei calcoli. Questo è utile anche per separare le preoccupazioni, migliorare la leggibilità (piuttosto che avere un'enorme entità di dominio contenente il codice complesso per tutte le preoccupazioni riguardanti gli Umani).
Sarebbe anche bello poter riutilizzare quella logica in diverse entità di dominio (ad es. Animal).
Quindi calculateZodiac()
istanzia un new Zodiac
, calculate()
roba e lo restituisce.
Ma, come detto sopra, questo può essere cambiato da qualcuno senza notare gli effetti collaterali diretti sull'entità del dominio.
E va nella direzione di un modello di dominio anemico, che è considerato un anti-modello di Martin Fowler.
Composizione
Quando si istanzia l'entità del dominio umano, fornire sempre l'implementazione Zodiac al suo costruttore.
Lo stesso rischio di prima, ma almeno la dipendenza è esplicita.
Inoltre, dopo aver fornito lo Zodiac, fai lo stesso per le classi PsychopathProfile, ExpectationOfLife, ProbabilityToBeBulliedBasedOnUnfortunadName, SportivePotential, ecc.
Troppe cose nel costruttore, ogni volta che istanziato. Non ideale ..