Det har gått mer än fem år sedan Eric Evans introducerade begreppet Domain-Driven Design, DDD, med sin bok Domain-Driven Design – Tackling Complexity in the Heart of Software.
Boken samlade ett antal centrala begrepp inom framförallt objektorienterad analys, design och implementation under ett gemensamt tak och har på många sätt skapat nytt liv i tankarna runt design av mjukvara med tydligt avstamp i dess problemdomän.
Introduktionen av begreppen domänhändelser (Domain Events), och Event Sourcing är troligen de områden där Domändriven design har utvecklats mest under de senaste åren. Särskilt arkitektur baserade runt designmönstret Command Query Responsibility Segregation, CQRS har rönt stor uppmärksamhet under ett par år och är ständigt återkommande ämnen på konferenser som Øredev, DDD eXchange och QCon. Både den ordinarie och den extrainsatta workshopen om CQRS på årets upplaga av Øredev är utsålda långt innan konferensstart.
CQRS är i grunden, lite beroende på vem man frågar, ett sätt att tydligt dela upp metoder så att läsning (query) och kommandon (commands) indelas i olika klasser. CQRS kombineras ofta med andra mönster som Event Sourcing och Domain Events för att skapa systemarkitekturer där interaktion med applikationen sker via kommandon och händelser. Läsning skiljs tydligt från skrivning, inte sällan med olika modeller för dessa.
CQRS i kombination med Event Sourcing vänder till viss del upp och ner på etablerade sätt att designa system och utmanar hur vi ser på systemarkitektur. En design baserad på Event Sourcing och CQRS öppnar upp en hel del intressanta möjligheter som är begränsade i en mer traditionell CRUD-arkitektur. Det kanske mest omtalade är möjligheten att bygga applikationer som helt separerar läsning från skrivning och där dessa två aktiviteter kan skalas oberoende av varandra för att hantera mycket omfattande genomströmning av data. Tidigt i tankarna runt DDD ansågs dessa typer av applikationer, med mycket data och höga krav på prestanda, som mindre lämpliga för Domain-Driven Design, en uppfattning som CQRS och Event Sourcing har kommit att till stor del förändra.
En annan intressant egenskap hos dessa typer av arkitektur är att vi genom att spara våra inkommande händelser och kommandon kan spåra inte bara nuvarande systemtillstånd, utan även hur vi kom dit. Detta, i sin tur, leder till andra möjligheter.
Om vi till exempel stöter på produktionsproblem kan vi i en testmiljö återställa systemet i ett tidigare tillstånd och sedan lägga på alla sparade kommandon igen för att på så sätt spåra exakt vad som gick fel. Detta är något som ofta kan vara svårt att göra baserat enbart på loggningsdata.
Det kan också ge oss möjlighet att köra om gamla händelser och kommandon i nya versioner av mjukvaran, eller mot alternativa modeller, och på så sätt skapa nya affärsdata ur tidigare händelser.
- CQRS Info
- Greg Young
- Greg Youngs kommande bok om CQRS
- Martin Fowler om CQRS
- Martin Fowler om Event Sourcing