mrt
04
2010

CQRS && Validatie && Business Rules

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.

  1. Als commands asynchroon afgehandeld gaan worden, hoe kan ik dan de validatie op de server doen en het de gebruiker melden dat deze validatie faalde?
  2. Hoe dwingen we business rules af die afhankelijk is van state die heel groot kan worden. Bekendste voorbeeld: een gebruiker moet een unieke gebruikersnaam hebben.
  3. Als aggregates volledig gescheiden zijn, hoe dwingen we dan business rules af die over meerdere aggregates heen gaan?

Ik wilde hier mijn ideeën over delen, aangezien ik denk dat deze vragen goed te beantwoorden zijn. In een hernieuwde poging om een korte post te schrijven, hier mijn drie antwoorden:

  1. Maak declaratief valideerbare commands. Valideer op de client. Niet-valide commands negeer je. Zie ook [3]
  2. Sla deze state in eerste instantie in-memory op in een onderdeel van de aggregate die de scope vertegenwoordigt (zie ook [4] voor een uitleg waarom er altijd zo’n scope is). Optimaliseer door de state buiten het geheugen te bewaren wanneer noodzakelijk. Gebruik maken van de read database is een extra optimalisatie.
  3. Dat kan niet. Althans, niet in de vorm van invariants, die gelden namelijk alleen binnen aggregates. Mogelijke oplossingsrichtingen: voeg de aggregates samen als ze onlosmakelijk verbonden blijken, kijk of je niet een aggregate mist die specifiek deze invariant afdwingt en ga anders uit van het gebruikelijke scenario en los uitzonderingen op met compensating actions.

Om het kort te houden, is deze post van allerlei extra uitleg ontdaan. Ik kan me voorstellen dat er nog vragen overblijven, die hoor ik dan ook graag.

 


[1] Zie deze post van Mark Nijhof (engels) voor een mooie beschrijving van wat ik bedoel met “CQRS architectuur”
[2] Greg Young zegt zelf ook CQRS geen architectuur te vinden. Die komt er wel vaak bij, maar heeft nog geen naam. Voorstel: “Circular Architecture”?
[3] Die is aardig uitgelegd in deze post van Udi Dahan (engels). Zoek op “Commands and validation”.
[4] Hier is een mooie uitleg over te vinden in een post van Jérémie Chassaing.

Geschreven door Rick | Tags: , |

Geen reacties - Leave a comment »

Rss feed voor commentaar op deze post. TrackBack URL

Leave a comment

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes

Better Tag Cloud