Berichten met de tag ‘Domain Driven Design’

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

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

Een aspect van het Observer patroon

02 januari 2009

Ik wil hier graag een aspect van het Observer-patroon bespreken. Het Observer-patroon bespreekt hoe een object kan aangeven dat het veranderd is, zonder harde koppelingen te maken. In het boek “Design Patterns” van de Gang of Four (GoF) wordt een aanvulling besproken. Het behandelt de situatie, dat een Observer alleen geïnteresseerd is in een bepaald Continue reading →

Ontkoppeling

19 oktober 2008

Dijkstra heeft ons jaren terug al verteld dat we koppeling in onze software laag moeten houden maar zaken die bijelkaarhoren moeten groeperen (high cohesion). Dit komt kort gezegd neer op goede indeling van verschillende onderdelen van software zodat onderdelen beter onafhankelijk van elkaar kunnen worden ontwikkeld en onderhouden. We zien dit bijvoorbeeld in object georienteerde talen terugkomen onder de noemer ‘encapsulatie’. Als we naar architectuurstijlen kijken zien we dat we component gebaseerd ofwel gelaagd kunnen werken om zo logische ontkoppeling van verschillende applicatieonderdelen te realiseren. Ik zou graag echter twee zaken omtrent ontkoppeling willen bediscussieren in deze post.
Lees verder >>

Dijkstra heeft ons jaren terug al verteld dat we koppeling in onze software laag moeten houden maar zaken die bijelkaarhoren moeten groeperen (high cohesion). Dit komt kort gezegd neer op goede indeling van verschillende onderdelen van software zodat onderdelen beter onafhankelijk van elkaar kunnen worden ontwikkeld en onderhouden. We zien dit bijvoorbeeld in object georienteerde talen terugkomen onder de noemer ‘encapsulatie’. Als we naar architectuurstijlen kijken zien we dat we component gebaseerd ofwel gelaagd kunnen werken om zo logische ontkoppeling van verschillende applicatieonderdelen te realiseren. Ik zou graag echter twee zaken omtrent ontkoppeling willen bediscussieren in deze post.
Lees verder >>

Dynamisch Programmeren (een uitdaging)

14 september 2008

Zo, nu deze verwarrende titel je aandacht heeft getrokken, zal ik eerst proberen die verwarring weg te nemen. Het dynamisch programmeren wat hier bedoeld wordt, heeft niets te maken met dynamische talen en ook niets met extra veel bewegen achter je toetsenbord en/of beeldscherm. Net zoals extreme programming niets te maken heeft met op bergtoppen of onder water programmeren.
Lees verder >>

Een poging om dynamisch programmeren zowel recursief als object georienteerd te implementeren, naar aanleiding van de uitdaging van André. De post sluit af met een nieuwe uitdaging aan de lezer om het model te verbeteren, waarbij naast eeuwige roem een fles wijn te verdienen valt.