[design] complexe domein logica.

[Alarmnummer]

Ik ben op dit moment Patterns of Enterprise Application Architecture van Martin Fowler aan het lezen. En ik vind het echt een fantastisch boek. Een van mijn zwakke punten op dit moment is toch wel de koppeling van domein objecten naar databases, en door dit boek krijg je hier gewoon veel meer inzicht in. Voor iedereen beter oo wil leren proggen zonder daar zelf ongelovelijk lang voor te moeten ploeteren, is dit boek echt een vette aanrader.

Maar om even ter zake te komen. In dit boek heeft hij het erg veel over complexe domein objecten. Ik ben helemaal gek op objecten en hoe complexer hoe beter. Maar helaas is er in enterprise applicaties ook vaak vreemde logica te vinden.

bv

-2 dagen na het einde van de maand dan moeten de rekeningen ingeleverd worden (anders nam een klant het contract niet aan)

-als er meer dan 15 bestellingen zijn gedaan per maand, dan kan 10% korting gegeven worden.

Dit zijn natuurlijk gruwelijke dingen om in je domein logica te gaan versleutelen, want dit is gewoon alles behalve logisch. Mijn vraag is daarom ook hoe jullie (als jullie het uberhaubt al doen) dit soort zaken gaan scheiden van je domein objecten? Ik had zelf al zitten denken aan allerlei vormen van strategies en speciale modules waar je een hele lading van die lelijke dingen kan dumpen, maar ik ben daar nog niet helemaal content mee. Ik wil dus weten hoe jullie dit soort problemen aanpakken.

[ACM]

Dat zijn toch eigenlijk dingen waar juist de query voor "bedoeld" is?

Zeker zo'n tellertje van 15 bestellingen in een maand, dat is een kwestie van 1 regel sql...
Maarja, dan ben je weer niet echt OO bezig en dat is wel weer een nadeel ervan (te sterke integratie met je DB wil je vast wel voorkomen )

[Glimi]

ACM schreef op 21 januari 2003 @ 22:35:
Dat zijn toch eigenlijk dingen waar juist de query voor "bedoeld" is?

Zeker zo'n tellertje van 15 bestellingen in een maand, dat is een kwestie van 1 regel sql...
Maarja, dan ben je weer niet echt OO bezig en dat is wel weer een nadeel ervan (te sterke integratie met je DB wil je vast wel voorkomen )

Mjah, daar heb je wel een punt. Want zulke zooi is eigenlijk geweldig om in stored procedures te gooien. Het is dan heerlijk snel, geen gore onbegrijpelijke query's in je code, maar je verspreid je objecten en logica wel enorm.

Maar wat is er niet OO aan dan? Je roept toch gewoon een procedure aan op een database? Een soort database API kun je het wel noemen dan

[Nexopheus]

Doet mij denken aan "rules" van "logic". Dus de standaard business logic met daarbij gekoppeld regels. Kan hiervoor niet zo 123 een design pattern voor aanwijzen (boek moest na 10 x verlengen toch echt terug!).

[Alarmnummer]

ACM schreef op 21 januari 2003 @ 22:35:
Dat zijn toch eigenlijk dingen waar juist de query voor "bedoeld" is?

Zeker zo'n tellertje van 15 bestellingen in een maand, dat is een kwestie van 1 regel sql...
Maarja, dan ben je weer niet echt OO bezig en dat is wel weer een nadeel ervan (te sterke integratie met je DB wil je vast wel voorkomen )

Idd. Ik wil totaal geen koppeling met de db, en alles in (of buiten?) de applicatie plaatsen.

[whoami]

Tja, design van enterprise applicaties is niet eenvoudig en om een goede koppeling tussen de database - datalogic en business logic te maken moet je meer dan goed nadenken.

De voorbeeldjes die jij aanhaalt horen thuis in de business-logic (domain logic) natuurlijk, en ook in dat boek gaat Fowler dat zo doen mbhv strategies.
Wat bedoel je dan eigenlijk met het scheiden van die zaken met uw domain-logic? Dit is gewoon 'domain-logic', dus hoort het ook in die laag thuis. Uw domain logic hoeft geen 1 op 1 afspiegeling te zijn van uw datamodel.
Het nemen van die beslissingen die jij aangehaald hebt, maakt deel uit van de domain logica, die logica gaat dus al zo'n beslissingen en bewerkingen uitvoeren. Een domain object is imho dus meer dan enkel een object dat de gegevens over een bepaald record bijhoudt. Dat heb je wel in je data-logic. De data-logic gaat de communicatie met de databank verzorgen en dus zorgen voor het ophalen van de gegevens en met die gegevens vul je uw domain-objecten op. Hetzelfde voor het saven.
Als je dus moet weten bv. hoeveel bestellingen een klant heeft, dan ga je ervoor zorgen dat uw domain-logica op een of andere manier uw data-logic aanspreekt en dat die data-logic de gewenste informatie teruggeeft aan de domain - logic. Op basis van die gegevens kun je dan beslissen welke strategy je moet uitvoeren (die strategy classes horen dus ook bij de domain-logica).

Wat ik ook moeilijk vind is , hoe je het best de koppeling maakt tussen de domain- ,data- en presentatielogica. Hoe laat je die 3 lagen het best samenwerken zonder dat ze sterk gekoppeld zijn. Ook hierop hoop ik een aantal goede antwoorden te vinden in dat boek.

[Alarmnummer]

Ik heb geen problemen hoor met het mappen naar de db (althans ik ben nog niet tegen onoverkomelijke problemen aangelopen met mijn fruitwinkeltje ) En verder weet ik dat het idd in de domein logic thuis hoort. Alleen de domein logic kan vrij complex worden (zie topic titel). Mijn vraag is dus hoe je in je domein logic dit soort zaken op een overzichtelijke manier kan onderbrengen.

En verder koppeling gui/domeinmodel => MVC, PAC

En verder krijg je altijd een koppeling van de datmodel naar de domein model. En je krijgt vaak een koppeling (tenzijn je PAC gebruikt) tussen je gui model en je domein model. Maar er is geen koppeling de andere kant op. De domein model hoeft niets te weten van de datamodel en de gui.

[ Voor 26% gewijzigd door Alarmnummer op 22-01-2003 11:44 ]

[whoami]

[nohtml]

Alarmnummer schreef op 22 January 2003 @ 11:40:
Alleen de domein logic kan vrij complex worden (zie topic titel). Mijn vraag is dus hoe je in je domein logic dit soort zaken op een overzichtelijke manier kan onderbrengen.

cf jouw voorbeeld:

Het bepalen wanneer de betalingen moeten gebeuren lijkt me niet zo complex. Je kunt, per leverancier/klant/whatevah in de databank een veld bijhouden die bepaald wanneer er moet betaald worden.

Je kunt - zoals in dat boek (en je nu ook al doet) - ook gebruik maken van strategies als dat nodig blijkt. (cfr dat voorbeeld over die verschillende soorten software-pakketten die elk een andere formule hebben om de prijs te berekenen).

Ivm die korting: ook daar kan je gebruik maken van de databank. Je kunt bijhouden hoeveel % korting klant A krijgt en hoeveel producten hij moet aangekocht hebben vooraleer hij die korting krijgt.

[Alarmnummer]

whoami schreef op 22 January 2003 @ 12:26:
[nohtml]
[...]


cf jouw voorbeeld:

Het bepalen wanneer de betalingen moeten gebeuren lijkt me niet zo complex. Je kunt, per leverancier/klant/whatevah in de databank een veld bijhouden die bepaald wanneer er moet betaald worden.

Je kunt - zoals in dat boek (en je nu ook al doet) - ook gebruik maken van strategies als dat nodig blijkt. (cfr dat voorbeeld over die verschillende soorten software-pakketten die elk een andere formule hebben om de prijs te berekenen).

Ivm die korting: ook daar kan je gebruik maken van de databank. Je kunt bijhouden hoeveel % korting klant A krijgt en hoeveel producten hij moet aangekocht hebben vooraleer hij die korting krijgt.

Mijn probleem zit hem in die gekke constructies. Kijk als iedereen volgens een soortgelijke formule korting krijgt, dan kan het idd erg eenvoudig opgezet worden. Maar sommige krijgen korting als ze meer dan 15 afnemen. Anders krijgen altijd korting. Anderen krijgen korting in de maanden dat hun kinderen jarig zijn en 5 keer een vrijdag in de maand zit. Dit soort gekke constructies zijn gewoon erg lastig om goed te modeleren.

Je kan natuurlijk aan de hand van een strategy die iedere klant bij zich kan dragen bepalen hoeveel korting er gegeven moet worden. Maar je kan dit beter niet direct onderbrengen bij je domein object zelf (of je zou veel met polymorfisme moeten werken).

Ik zoek niet zozeer een concrete oplossing voor dit probleem, maar het gaat me meer om een discussie over hoe ontwerpers dit soort problemen nou aanpakken.

[Orphix]

Als het werkelijk veel verschilt per klant en is het redelijk complex zou je kunnen denken die logica op te splitsen in andere bestanden en die per klant te linken. Je komt dan al snel in talen voor expert- (of kennis-)systemen. Lijsten van voorwaardes die worden afgegaan om zo tot een eindresultaat te komen. Denk hierbij bijvoorbeeld aan de bepaling van een verzekeringspremie voor een bepaald persoon, dit kan van individu tot individu verschillen.

Ik heb hier verder geen ervaring mee en hoe makkelijk dergelijke systemen/talen te koppelen zijn maar door de scheiding kunnen bv (hogere) managers beter prijsafspraken bepalen met hun klanten en deze zelf toepassen.

Maar het geheel ligt natuurlijk helemaal aan de situatie en hoe ver je wilt gaan.

[whoami]

Orphix schreef op 22 January 2003 @ 13:15:

Maar het geheel ligt natuurlijk helemaal aan de situatie en hoe ver je wilt gaan.

Idd, waar trek je de lijn? Dat is heel belangrijk. Je hebt altijd wel uitzonderingen, maar ergens wordt er toch een grens getrokken.
Je zult wel in enterprise applications uitzonderingen en rare regels hebben, maar het zal zelden of nooit voorkomen dat bv. een vertegenwoordiger nu nog zelf korting-strategiën voor zijn klanten op eigen houtje kan bepalen.

[vinnux]

Het belangrijkste is dat je je aan je concept/ontwerp houd. Probeer je ontwerp zo generiek mogelijk te maken, waardoor veel van dit soort regels er makkelijk in kunnen worden gezet. Dan mag het systeem uiteindelijk iets minder slikkie en coolio zijn, maar je hebt wel meer mogelijkheden om dingen uit te breiden. In onderhoud zit vaak meer werk dan de hele bouw, waarom dan niet meer concentreren op onderhoud door het eenvoudiger en generieker op te zetten. Misschien is het iets meer codeerwerk, maar beter uitbreidbaar.

[whoami]

vgouw schreef op 22 januari 2003 @ 16:02:
Het belangrijkste is dat je je aan je concept/ontwerp houd. Probeer je ontwerp zo generiek mogelijk te maken, waardoor veel van dit soort regels er makkelijk in kunnen worden gezet. Dan mag het systeem uiteindelijk iets minder slikkie en coolio zijn, maar je hebt wel meer mogelijkheden om dingen uit te breiden. In onderhoud zit vaak meer werk dan de hele bouw, waarom dan niet meer concentreren op onderhoud door het eenvoudiger en generieker op te zetten. Misschien is het iets meer codeerwerk, maar beter uitbreidbaar.

Ik denk dat dit het juist is waar Alarmnummer op zoek naar is... Hoe hij het zo generiek mogelijk kan aanpakken...

[Alarmnummer]

whoami schreef op 22 January 2003 @ 16:03:

[...]


Ik denk dat dit het juist is waar Alarmnummer op zoek naar is... Hoe hij het zo generiek mogelijk kan aanpakken...

Ik ben niet zozeer op zoek naar een zo generiek mogelijke oplossing. Ik ben eigelijk helemaal niet op zoek naar een oplossing. Ik wil gewoon jullie gedachtes er eens over horen omdat ik hier zelf ook wel eens over zit te prakadenken.