Berichten met de tag ‘DDD’

Test op test op test

06 februari 2011

Deze week liet ik aan een collega (Rob Vens) een aantal testen zien voor een recent project van mijn hand. Hij vond ze wel mooi om te zien en ik bedacht me dat ik deze nog niet gedeeld heb met mijn collega’s en andere geïnteresseerden. Dus dat leek me mooi om hier ook even uit de doeken te doen. Het is gebaseerd op werk van Greg Young en Mark Nijhof. Wat ik er met name aan heb toegevoegd is het afleiden van specifiekere testcases van generiekere testcases, waardoor complexere scenarios op simpelere scenarios bouwen, zonder dat er dubbeling optreedt.
Lees verder >>

Deze week liet ik aan een collega (Rob Vens) een aantal testen zien voor een recent project van mijn hand. Hij vond ze wel mooi om te zien en ik bedacht me dat ik deze nog niet gedeeld heb met mijn collega’s en andere geïnteresseerden. Dus dat leek me mooi om hier ook even uit de doeken te doen. Het is gebaseerd op werk van Greg Young en Mark Nijhof. Wat ik er met name aan heb toegevoegd is het afleiden van specifiekere testcases van generiekere testcases, waardoor complexere scenarios op simpelere scenarios bouwen, zonder dat er dubbeling optreedt.
Lees verder >>

Architectuur & Software design – hoe?

09 januari 2011

Bij trainingen en presentaties die ik geef over DDD, komt altijd de vraag op: maar hoe doe je dat ontwerpen nou precies, welk proces volg je daarvoor? Een logische vraag. En tevens één die lastig te beantwoorden is. Niet dat er helemaal geen antwoorden zijn hoor: er zijn vele ontwerpprocessen, methodologiën en checklists. Maar als je je daarin verdiept (heb er inmiddels redelijk wat van gelezen en toegepast), blijkt elke keer weer dat het met name ‘kapstokken’ zijn om je werkzaamheden aan te hangen. Wat ik daarmee bedoel: het zijn planningen met daarin fases en mogelijk zelfs specifieke sessies, inhoudelijk beschreven, liefst ook met het te verwachten eindresultaat. Maar wát je nou precies doet in zo’n sessie?
Lees verder >>

Bij trainingen en presentaties die ik geef over DDD, komt altijd de vraag op: maar hoe doe je dat ontwerpen nou precies, welk proces volg je daarvoor? Een logische vraag. En tevens één die lastig te beantwoorden is. Niet dat er helemaal geen antwoorden zijn hoor: er zijn vele ontwerpprocessen, methodologiën en checklists. Maar als je je daarin verdiept (heb er inmiddels redelijk wat van gelezen en toegepast), blijkt elke keer weer dat het met name ‘kapstokken’ zijn om je werkzaamheden aan te hangen. Wat ik daarmee bedoel: het zijn planningen met daarin fases en mogelijk zelfs specifieke sessies, inhoudelijk beschreven, liefst ook met het te verwachten eindresultaat. Maar wát je nou precies doet in zo’n sessie?
Lees verder >>

Value objects spelen ook maar een rol

12 augustus 2010

De afgelopen dagen had ik een interessante discussie op de DDD mailinglist over value objects.
Lees verder >>

De afgelopen dagen had ik een interessante discussie op de DDD mailinglist over value objects. De discussie ging over de niet-wijzigbaarheid (immutability) van value objects. Het vreemde is dat veel ontwikkelaars (in de rol van modelleur) deze niet-wijzigbaarheid benadrukken. Hij komt ook altijd op. Terwijl het volgens mij niet de essentie is.

No exceptions made

20 juli 2010

Naar aanleiding van een bevinding tijdens een interne project code review  en een artikel in het laatste Java Magazine hadden we een interessante discussie over de redenen om exceptions toe te passen. Uiteindelijk kon ik zelf achter twee vuistregels staan, één die ik zelf bedacht had, de ander van een collega.
Lees verder >>

Naar aanleiding van een bevinding tijdens een interne project code review  en een artikel in het laatste Java Magazine hadden we een interessante discussie over de redenen om exceptions toe te passen. Uiteindelijk kon ik zelf achter twee vuistregels staan, één die ik zelf bedacht had, de ander van een collega.
Lees verder >>

CQRS & de bijkomende architectuur

09 maart 2010

In mijn vorige blogpost deed ik in de voetnoten een voorstel om de architectuur die vaak meekomt met het patroon CQRS anders te noemen. Ik dacht aan een “Circular Architecture” om hem duidelijk te contrasteren met een “Layered Architecture”. Na een korte discussie met Greg Young en Alistair Cockburn hierover besloot ik om het idee nog eens even goed onder de loep te nemen. Zij claimden allebei dat de “Hexagonal Architecture” van Alistair Cockburn deze architectuur al voldoende beschreef. Dat zette me wel aan het denken, aangezien ik het oordeel van beide zeer respecteer. Eerst enkele definities waar ik vanuit ga
Lees verder >>

In mijn vorige blogpost deed ik in de voetnoten een voorstel om de architectuur die vaak meekomt met het patroon CQRS anders te noemen. Ik dacht aan een “Circular Architecture” om hem duidelijk te contrasteren met een “Layered Architecture”. Na een korte discussie met Greg Young en Alistair Cockburn hierover besloot ik om het idee nog eens even goed onder de loep te nemen. Zij claimden allebei dat de “Hexagonal Architecture” van Alistair Cockburn deze architectuur al voldoende beschreef. Dat zette me wel aan het denken, aangezien ik het oordeel van beide zeer respecteer. Eerst enkele definities waar ik vanuit ga
Lees verder >>

CQRS && Validatie && Business Rules

04 maart 2010

Validatie en business rules binnen een CQRS architectuur [1][2] blijven onderwerpen die vragen oproepen voor degenen die er voor het eerst van horen. Drie specifieke vragen worden daarover vaak  gesteld: hoe werkt de validatie van commands, hoe kun je business rules afdwingen over grote collections (state) en hoe werkt het afdwingen van business rules over aggregates heen? Hopelijk kan ik een aantal lezers helpen met mijn drie antwoorden daarop. Eerst de vragen
Lees verder >>

Validatie en business rules binnen een CQRS architectuur [1][2] blijven onderwerpen die vragen oproepen voor degenen die er voor het eerst van horen. Drie specifieke vragen worden daarover vaak  gesteld: hoe werkt de validatie van commands, hoe kun je business rules afdwingen over grote collections (state) en hoe werkt het afdwingen van business rules over aggregates heen? Hopelijk kan ik een aantal lezers helpen met mijn drie antwoorden daarop. Eerst de vragen
Lees verder >>

Domain model Reporting, Sir!

04 februari 2010

In deze post beschrijf ik een praktijk case van het ontwerp van rapportage functionaliteit op een model gedreven applicatie. De applicatie is in een zonnebloemmodel opgebouwd rond een object-georiënteerd domeinmodel, wat tot nu toe een voornamelijk actief model is wat gedreven en niet de alomtegenwoordige CRUD functionaliteit biedt. De bedoeling is dat dat ook zo blijft. Over enige tijd hoop ik deze post op te kunnen volgen met resultaten uit de praktijk.
Lees verder >>

In deze post beschrijf ik een praktijk case van het ontwerp van rapportage functionaliteit op een model gedreven applicatie. De applicatie is in een zonnebloemmodel opgebouwd rond een object-georiënteerd domeinmodel, wat tot nu toe een voornamelijk actief model is wat gedreven en niet de alomtegenwoordige CRUD functionaliteit biedt. De bedoeling is dat dat ook zo blijft. Over enige tijd hoop ik deze post op te kunnen volgen met resultaten uit de praktijk.
Lees verder >>

Het nieuwe paradigma?

17 januari 2010

Binnen software ontwikkelland ontstaat meer en meer aandacht voor event gebaseerde systemen. Bertrand Meyer schreef hier in 2003 al een artikel over event driven design. Gregory Young heeft met zijn CQRS benadering van systeembouw een interessante structuur neergezet. Binnen Sogyo hebben we inmiddels ook de eerste event gedreven implementaties in de praktijk toegepast. De voorlopige conclusies zijn dat deze vorm van systeemontwerp en -bouw zeer goed kunnen werken, maar slechts voor een beperkte set aan toepassingen.
Lees verder >>

Binnen software ontwikkelland ontstaat meer en meer aandacht voor event gebaseerde systemen. Bertrand Meyer schreef hier in 2003 al een artikel over event driven design. Gregory Young heeft met zijn CQRS benadering van systeembouw een interessante structuur neergezet. Binnen Sogyo hebben we inmiddels ook de eerste event gedreven implementaties in de praktijk toegepast. De voorlopige conclusies zijn dat deze vorm van systeemontwerp en -bouw zeer goed kunnen werken, maar slechts voor een beperkte set aan toepassingen.
Lees verder >>

TDD + DDD = BDD

09 juni 2009

In vervolg op mijn vorige post over TDD vs DbC wilde ik verder uitleggen waarom ik vind dat TDD iets anders is dan alleen unit tests. Sterker nog: TDD heeft in het begin helemaal niets met unit tests te maken, volgens mij. In den beginne heb je namelijk nog helemaal geen units.
Lees verder >>

In vervolg op mijn vorige post over TDD vs DbC wilde ik verder uitleggen waarom ik vind dat TDD iets anders is dan alleen unit tests. Sterker nog: TDD heeft in het begin helemaal niets met unit tests te maken, volgens mij. In den beginne heb je namelijk nog helemaal geen units.
Lees verder >>

Modellering: Wat besteed je uit aan een framework?

21 mei 2009

Afgelopen week had ik met een aantal collega’s een discussie over modellering. De situatie was als volgt: in een bepaalde applicatie was een (N)Hibernate mapping gedaan van een collectie met een List mapping. Dit was gedaan om NHibernate deze lijst een volgorde te kunnen laten bijhouden – en daar bleken wat onverwachte problemen mee te zijn. Mijn vraag was meteen: waarom zou je een List gebruiken en geen Bag? Volgorde is toch niet interessant? Voor deze specifieke klantsituatie was de volgorde wel degelijk interessant was het antwoord: het was door de klant letterlijk gevraagd om in deze lijsten volgordes te kunnen aangeven.
Lees verder >>

Afgelopen week had ik met een aantal collega’s een discussie over modellering. De situatie was als volgt: in een bepaalde applicatie was een (N)Hibernate mapping gedaan van een collectie met een List mapping. Dit was gedaan om NHibernate deze lijst een volgorde te kunnen laten bijhouden – en daar bleken wat onverwachte problemen mee te zijn. Mijn vraag was meteen: waarom zou je een List gebruiken en geen Bag? Volgorde is toch niet interessant? Voor deze specifieke klantsituatie was de volgorde wel degelijk interessant was het antwoord: het was door de klant letterlijk gevraagd om in deze lijsten volgordes te kunnen aangeven.
Lees verder >>