Domain Driven Design and Object-Relational Modeling

Bij het ontwikkelen van business applications kan de applicatie logisch gezien altijd worden opgedeeld in drie lagen: User Interface – Business Logic – Data. Hoe deze lagen worden geimplementeerd en op elkaar aansluiten hangt grotendeels af van de gekozen architectuur en techniek. Met name de implementatie van de Business Logica en de Data-laag blijft altijd een uitdaging. Dit komt doordat de Business Logica veelal in een object-georienteerde taal wordt geprogrammeerd (bijv C# of Java) en alle data in relationele databases wordt opgeslagen. Er moet dus een bepaalde aanpak worden gekozen om de data vanuit de database in te laden, daar operaties op uit te voeren en deze weer op te slaan. In sommige gevallen wordt deze stap om performance-redenen zelfs overgeslagen en wordt de logica in de database geimplementeerd.

Er moet echter een methode gekozen worden om een brug te slaan tussen de wereld van de OO-taal en de wereld van het gekozen RDBMS. Zo’n methode kan worden gezien als ‘data driven’ of ‘domain driven’. Data driven is hierbij de oudere en conventionele manier van ontwikkelen. Bij de data driven aanpak wordt de database en het bijbehorende data-model als leidend gezien en wordt de data uit de database in de vorm van het gekozen data-model opgehaald en verwerkt. De functies die de business logica bevatten zijn veelal volledig gescheiden van de structuren die de data bevatten.

Bij de domain driven aanpak wordt het business domein als leidend gezien. Er wordt eerst een model gecreëerd die de business zo goed mogelijk weergeeft, om daar vervolgens in code een zo representatief mogelijk object-model van te bouwen. De objecten uit zo’n model bevatten typisch zowel data als business logica en zijn daarbij veel trouwer aan het pure OO-paradigma. Het probleem van deze aanpak zit echter vooral in de kloof die zich tussen de vorm van deze objecten en de vorm van de data in de database bevindt. Dit wordt ook wel de ‘impedance mismatch’ genoemd.

Op dit moment hanteert Info Support een data driven aanpak als standaard. Het is echter interessant om te onderzoeken in hoeverre de domain driven aanpak in de praktijk toe te passen is, vanwege de vele voordelen in termen van onderhoudbaarheid en uitbreidbaarheid van code.

Opdracht

Onderzoek wat de voor- en nadelen zijn van de Domain Driven aanpak t.o.v. de Data Driven aanpak en stel een aantal guide lines op die gevolgd zouden moeten worden als er Domain Driven gewerkt gaat worden. Neem in je onderzoek ook tools als het Entity Framework en NHibernate mee. Wat zijn de voor- en nadelen van zulke ORM-tools? In welke gevallen is het beter om juist niet voor een dergelijke tool te kiezen? Hoe zit het met performance? Pas de uitkomsten van je onderzoek toe in een voorbeeldcasus.

Benodigde kennis &/of Interesse

Kennis van OO programmeren en concepten, SQL, UML Modeling