[ALG] Domein gericht denken

[Cuball]

Ik ben mijn manier van denken en de manier van applicatie opbouw wat meer Domein gericht aan het opbouwen. Hiervoor had ik graag eens een oefening met jullie samen uitgewerkt.

Stel het volgende scenario (aangepaste verse uit een use case):

We hebben een toepassing die kuisvrouwen beheert, een kuisvrouw gaat schoonmaken bij verschillende klanten. Wanneer een kuisvrouw bij een klant schoongemaakt heeft wordt hiervoor een prestatie geregistreerd (dit is dus een een link tussen klant, kuisvrouw en tijdstip met datum, + andere properties). Een kuisvrouw kan nu per dag verschillende klanten doen. Wat we nu moeten weten is de totale afstand die een kuisvrouw per dag doet bij het pendelen tussen de verschillende klanten.

Hiervoor heb ik in pseudocode volgende opstelling:

Java:

public class AfstandCalculator {
    
    private PrestatieDAO prestatiesDAO  = null;
    private AftandService afstandService = null;

    public double berekenAfstandOpDag(Kuisvrouw kuisvrouw, Datum dat) {
        List prestaties = prestatieDAO.zoekprestatiesVoorKuisVrouw(kuisvrouw);
        return berekenAfstandTussenPresatiesEnGebruikAfstandService(prestaties, afstandService);
    }
    
}

vanuit mijn servicelaag ga ik nu dus AfstandCalculator gebruiken om de totale dagafstand van de kuisvrouw te bereken. (afstandcalulator is een singleton uit de spring application context, evenals, prestatieDAO en afstandService)

Hoe zouden jullie hier een meer domein model achtige oplossing van maken ?

Zou ik de berekening van afstanden op prestatie niveau moeten laten gebeuren ?

Java:

prestatie.berekenAfstandTotPrestatie(anderePrestatie)

ik kom er niet echt hoe ik dit zo clean mogelijk kan oplossen

[Verwijderd]

Ik vermoed dat de logica onderdeel zou moeten zijn van de verzameling. Afstand is immers een eigenschap van de collectie en niet van de mevrouw of een enkele werkplek.

[JKVA]

Blijkbaar is Werkdag iets in jullie domein?

[Cuball]

JKVA schreef op maandag 18 juni 2007 @ 17:56:
Blijkbaar is Werkdag iets in jullie domein?

Werkdag hebben we niet aan gedacht, we zijn vanuit prestatie gestart en gedefinieerd als een kuisvrouw, een klant en dit op een bepaald tijdstip (=tijd en datum)

[JKVA]

Cuball schreef op maandag 18 juni 2007 @ 19:28:
[...]


Werkdag hebben we niet aan gedacht, we zijn vanuit prestatie gestart en gedefinieerd als een kuisvrouw, een klant en dit op een bepaald tijdstip (=tijd en datum)

Dan zou ik dus een klasse (Werkdag ofzo) introduceren die de datum property in de prestatie vervangt. De associatie loopt 2 kanten op, dus werkdag krijgt een lijst met prestaties en een prestatie is gekoppeld aan een werkdag. Op die manier kun je berekeningen/acties over de lijst mooi in de werkdag zetten en staan ze op een logische plaats.

Als je met een gewone datum property werkt, kom je altijd in de problemen met dergelijke zaken en dwing je jezelf richting een niet-domein-gerichte benadering. Het wordt dan snel een oplossing waar je in de database een count ofzo doet vanuit een typische servicelaag. En bij een domein gerichte benadering wil je niet alle logica in een servicelaag hebben.

[Cuball]

JKVA schreef op dinsdag 19 juni 2007 @ 07:46:
[...]

Dan zou ik dus een klasse (Werkdag ofzo) introduceren die de datum property in de prestatie vervangt. De associatie loopt 2 kanten op, dus werkdag krijgt een lijst met prestaties en een prestatie is gekoppeld aan een werkdag. Op die manier kun je berekeningen/acties over de lijst mooi in de werkdag zetten en staan ze op een logische plaats.

Dit lijkt me inderdaad een meer naar het domein gerichte oplossing. Wat ik me wel afvroeg, voor elke prestatie moet ik nog de afstand gaan berekenen, hiervoor heb ik dus die AfstandService nodig. Als je domein gericht gaat werken ga je dan overal dergelijke services en repositories gaan injecteren?

Ik heb mijn manier van werken reeds in http://gathering.tweakers.net/forum/list_messages/1227086
beschreven. Via Spring en Aspject doe ik het nu, maar voorlopig heb ik het nog maar op enkele plaatsen in mijn applicatie gedaan, ik vroeg me af wat er gebeurd als ik dit doortrek en dan in verschillende domein objecten overal repositories ga injecteren...zal dit niet een enorme overhead gaan meebrengen ? Ook kom je zo in problemen met fout afhandeling, een simpele call op je domein object kan nu zorgen dat je een onverwachte runtime exceptie krijgt, geen probleem als dit binnen een transactie gebeurd, dan kan je die gaan afhandelen, maar je kan deze call evengoed buiten een transactie uitvoeren en als je dan een exceptie krijgt...

[JKVA]

Nou, zoals ik DDD zie, is je domein onafhankelijk van de services die ermee werken, zoals persistency en presentatie. Je domein kent dus je services niet. Om programmeren gemakkelijk te maken en om voor abstractie te zorgen, zou ik met een servicelaag werken die de domeinobjecten aanroept en naderhand persisteert o.i.d. De domeinobjecten doen zelf niets, behalve regels uitvoeren.