Riutilizzo della logica dell'entità di dominio

0

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 ..

posta Kamafeather 14.12.2018 - 13:04
fonte

2 risposte

1

Potresti aver bisogno di una classe BirthDate o di una struttura che contenga tutta la logica di cui stai parlando.

Con solo un piccolo brain storming, ci sono un certo numero di cose che puoi ricavare da una "data di nascita" che sarebbe perfettamente adatta per includere in una classe di BirthDate:

  • Calcolo del segno zodiacale
  • Calcolo della "sfortuna"
  • Età (yup, RightNow - BirthDate = age )

Se hai una lingua che supporta l'overloading dell'operatore, puoi anche sovraccaricare gli operatori matematici e logici in modo da poter fare cose come:

var birthDate = new BirthDate(1982, 12, 14);
var theYear2000 = DateTime.Parse("1/1/2000");
var isBornAfterYear2000 = birthDate > theYear2000;

Console.WriteLine(isBornAfterYear2000); // Prints "False"

Di solito quando trovi la logica e i dati che coprono più tipi nella tua applicazione, significa semplicemente che ti manca un tipo che incapsula sia i dati che la logica, e quindi quelle altre classi devono usare questa nuova classe mancante.

Puoi ancora disporre di un metodo Human.calculateZodiac() , che quindi delega tale operazione al suo oggetto interno BirthDate per restituire il valore corretto.

    
risposta data 14.12.2018 - 13:24
fonte
0

Generalmente, più grande diventa un progetto, il più bello mi piace che i miei modelli siano.

So che dopo il DDD dovresti avere modelli di dominio sufficientemente coerenti da eseguire calcoli specifici del modello di dominio ... ma nel secondo caso hai un calcolo che si applica al di fuori del tuo modello di dominio, per me pulisce davvero il codice e fornisce più benefici per fornire quel calcolo da qualche altra parte (classe di servizio, utilità, ecc.)

Il mio suggerimento sarebbe:

birthDateCalculatorService.calculateZodiacSign(myHuman.getBirthDate());
birthDateCalculatorService.hasBadLuck(myDog.getBirthDate());
    
risposta data 14.12.2018 - 13:11
fonte