Základní myšlenky Domain Driven Designu, CQRS a Event Sourcingu

Tyhle tři pojmy znamenají navzájem se doplňující soubor technik a postupů, s jejichž pomocí lze vyvíjet software a psát jeho kód tak, aby se zvýšila jeho udržitelnost a rozšiřitelnost. Lze je aplikovat snad v každém moderním programovacím jazyce a nejsou závislé na žádných konkrétních technologiích, frameworcích, knihovnách ani databázích. Doplňují ostatní nástroje, které podporují záměry extreme programmingu

Co je to Domain Driven Design?

Ústředním kamenem u této techniky jsou dvě věci: ubiquitous language (všudypřítomný jazyk) a bounded context (vymezený kontext).

Nejčastějším (a snad i jediným? :)) důvodem, proč vyvíjíme software je to, že nám nějakým způsobem pomáhá řešit problémy v reálném světě. Ať už jsou to logistické aplikace, eshopy, aukční servery, diskuze, nebo třeba hry, vždycky mají nějaký více či méně popsaný (nebo promyšlený) koncept, jak by měly fungovat, aby splnily naše cíle.

Myšlenka všudypřítomného jazyka říká, že abysme mohli efektivně komunikovat vývoj a software jako takový, je extrémě důležité všechny koncepty definovat a vytvořit pro ně konkrétní jazyk, který budou používat všichni, co mají se softwarem cokoliv dočinění. Od managerů, přes programátory, správce sytému, až po konečné uživatele.

Myšlenka vymezeného kontextu nám nadruhou stranu připomíná, že slovo všudypřítomný je míněno jenom a pouze ve smyslu, že prostupuje všemi skupinami lidí, kteří interagují s vyvíjeným softwarem. Nikoliv ale všemi částmi, ze kterých se skládá. V každé z těchto částí – kontextů, může mít věc, která má stejnou identitu, označena jinými pojmy a/nebo může řešit rozdílné problémy:

Zákazník v různých bounded contextech. Zdroj: http://www.informit.com/articles/article.aspx?p=2738465&seqNum=3

Software proto dělíme do menších, striktně oddělených částí, kde každá má svůj všudypřítomný jazyk. Pří komunikaci mezi těmito částmi jsou pak koncepty překládány:

Zdroj: Eric Evans, Domain Driven Design – Tackling Complexity in the Heart of Software, strana 344

Microservices jsou extrémní příklad striktní oddělenosti, ale nejsou nutnou podmínkou k jejímu dosažení. Zároveň samy o sobě nezaručují oddělenost jazyka jako takového – pořád mohou sdílet jeden a ten samý model a jazyk, což s rostoucím systémem přináší problémy.

Mapa Domain Driven Design konceptů

Mapa konceptů Domain Driven Designu Zdroj: Eric Evans, Domain Driven Design – Tackling Complexity in the Heart of Software

Co je to CQRS?

Zkratka pro Command Query Responsibility Separation, tedy přísné oddělení zápisu a čtení. Tato technika učí, že je přínosné přísně oddělit zápis a čtení na příkazy (commands – způsobují změny v systému, ale nic nevracejí – pouze vytvářejí události) a dotazy (queries – čtou uložená data v systému a vrací nějaký výsledek, ale nic v systému nemění). To umožňuje jednak škálovat celý systém (lze mít x serverů pro čtení) a také efektivně snížit provázanost systému.

Jak funguje CQRS? Zroj: https://martinfowler.com/bliki/CQRS.html

Co je to Event Sourcing?

Myšlenka této techniky je založená na tom, že lze a také je často výhodné ukládat data v aplikaci tak, že zaznamenáme veškeré události (eventy), které se v systému odehrály. Když toto přísně dodržíme, tak jsme schopni později (, průběžně – kdykoliv) vygenerovat jakoukékoliv struktury v jakékoliv databázi, které mohou sloužit k veškerým dotazům na stav aplikace a do kterých bysme jinak “tradicionálně” ukládali primární stav databáze.

S využitím Event Sourcingu existuje auditlog všeho, co se v aplikaci odehrálo a je možné zpětně vygenerovat jakákoliv data, která by byla při tradicionálním přístupu – stavové databázi – historicky ztracena a šlo by je začít měřit až po tom, co se patřičně upraví aplikace. Když se aplikace kvůli databázi načítá pomalu, lze vše migrovat na jinou s libovolnou strukturou a bez ztráty informací.

Domain-Driven Design, CQRS a Event sourcing dohromady

Ačkoliv tyhle techniky jde použít samostatně, nebo v libovolné kombinaci, tak dohromady se tyto techniky dost elegantně doplňují. Každá z těchto technik má své výhody i úskalí, ale při použítí všech třech, lze některá úskalí výrazně potlačit a některá se jejich spojením dokonce “automaticky” vyřeší. Jsem rád, že pro PHP 7.1 už existuje toolbox (prostě composer knihovna) prooph, který řeší implementační detaily těchto technik a nabízí různé knihovny řešící jejich různé aspekty. Já jsem ty nejdůležitější z nich sjednotil do nette extension lidskasila/prooph, díky které lze tyto knihovny konfigurovat přes nette neon config. Přikládám obrázek, který znázorňuje, jak tento toolbox funguje v celé své síle a zároveň znázorňuje celou flow s použitím výše zmíněných technik:

Zdroj: http://getprooph.org/docs/html/overview/prooph-in-a-nutshell.html

Příspěvek byl publikován v rubrice Nezařazené a jeho autorem je tomcizek. Můžete si jeho odkaz uložit mezi své oblíbené záložky nebo ho sdílet s přáteli.