Event Sourcing, CQRS, mikrosluzby – kde zacat?

Zacinam novy projekt ktory je zalozeny na mikrosluzbach a bude vyuzivat event sourcing a cqrs. Som na to sam a nemam s tymto ziadne prakticke skusenosti. Urobil som si taky mensi event storming a cca viem co chcem spravit(+ appka je prakticky len nova verzia existujuceho monolitu), lenze problem je ze ani neviem kde zacat ak ide o samotny kod. Teorie uz som vstrebal dost a chcem sa pustit do kodenia. Kedze to nie je monolit kde treba ist a,b,c,d.. + vecsinou ide o nejaky framework, tak je cela architektura a sluzby nehmotna, ak by som to tak nazval. Tak by ma zaujimalo, ak ste riesili navrh od zakladu, ako ste sa toho ujali, aky plan postupu ste si spravili a eventuelne ake chyby ste spravili v zaciatku. Technologia ma nezaujima, to sa da vzd yzmenit(db, msg broker, jazyk...), ide mi len o to ako realne zacat kodit takyto projekt.

Toto je klasický problém dekompozice komplexního řešení. Musíš dobře znát kdo a jak bude systém používat. Od toho se můžeš posunout dále k tomu, co bude systém umět a od toho k jednotlivým částem, které od sebe lze izolovat. V podstatě se jedná o tzv. "Separation of Concerns".Krásným příkladem je prakticky jakákoliv online služba nebo web a rozesílání emailů. Zajištění emailů je klasická mikroslužba, která musí být oddělená, a z více různých míst do ní mohou chodit požadavky na odeslání konkrétního emailu. Tohle v podstatě není o tom začít kódovat, ale spíše si sednout s papírem a tužkou a věnovat se architektuře celého řešení. Jako určité "mezníky" je dobré všímat si funkčních celků; částí, které vyžadují určitý čas na zpracování (ty je totiž ideální řešit přes msg broker); částí, jejichž vstup a výstup je hodně nezávislý na zbytku aplikace; částí, které se opakovaně používají na různých místech; apod. Hodně ti pomůže postupovat od toho high-level konceptu níže. Vezmeš určitou operaci, kterou může uživatel udělat, a rozepíšeš ji na to, co se stane... Když uživatel klikne na toto, tak se vygeneruje report, uloží se jako PDFko, zašle se informace emailem, pošle se notifikace do mobilu, atd. atd. A z toho ti jasně vychází, že abys mohl naprogramovat tento blok, tak musíš umět zaslat email, notifikaci do mobilu a vygenerovat PDFko. K tomu, abys mohl udělat PDF, potřebuješ data z nějakého generátoru reportů, atd. A tímhle způsobem si můžeš nejen rozložit tu danou operaci, ale určit i prioritu toho, co potřebuješ mít, abys mohl udělat další krok a hnedka se tím pádem nabízí to, co se dá programovat. Samozřejmě musíš velmi precizně definovat rozhraní - to je u mikroslužeb klíčové.

https://github.com/broadway/broadway a hlavne https://pilsniak.com/cqrs-es-php-prooph/ su dost dobre, prakticke, vysvetlenie ako na to.

Obnovim temu.Ako riesit pripady kedy mate privela vztahov medzi entitami? Napriklad jeden sklad vs tisice poloziek, jeden katalog vs tisice clankov, jedna liga vs tisice hracov.Logicky musi byt agregat polozka a nie sklad, respektive clanok a nie katalog. Nakolko by bolo neprakticke mat agregat skladu ktory by v sebe udrzoval napriklad 10 000 poloziek(entit). I ked ide o spravne boundaries, z technickeho hladiska je to prakticky nerealizovatelne kedze neexistuje limit vztahov(sklad moze mat jednu polozku, ale aj milion). Problem mi ale vznika napriklad ak je vykonavana akcia ktora by mala byt v ramci agregatu(napr ten sklad), ako je napriklad rezervacia nejakej polozky, ale kedze sklad nie je agregat ale je to prave polozka, tak sa tato akcia(command) deje mimo boundaries skladu a v ramci boundaries polozky. A napriklad aj stav skladu sa musi zistovat dopytovanim na register poloziek a nie skladu. Cize hlavne ide o to ze logika sa presuva z vnutra agregatu von. Je to sice stale v ramci domeny ale uz su tie boundaries pošahane.Samozrejme sklad moze byt vnimany ako domena a teda toto by bolo v poriadku, lenze ak je viacej skladov, pripadne do toho zapadaju este ine entity(prevodka, prijemka, vydajka) a podobne veci tak sa to uz zacina komplikovat a DDD mi uplne nesedi potom.

Zajímavé téma. Přijde mi, že si to komplikuješ tím, že chceš s částmi (článek, položka ve skladu) manipulovat přes jejich nadřazenou úroveň (katalog, sklad). Ono to ale přece ani u tvého příkladu nedává smysl - rezervace je změna stavu položky, a to není úkol skladu, ale položky samotné: Item.reserve() Item.changeState(States::RESERVED) ale ne Stock.reserve(Item) (To neznamená, že neexistuje ItemManager, který neumí načíst, zarezervovat/vyexpedovat/odepsat a zase uložit položky - to ale není "sklad", kopírující lidský koncept, ale pomocná třída). Vysvětlím to ještě jinak na příkladu katalog - článek. Co dává katalogu "pravomoc" upravovat článek? Článek přece patří do různých kategorií, do štítků, napsali ho autoři atd. Proč by měl mít přednost Catalog.publish(Article) před Category.publish(Article) nebo před Author.publish(Article) ? Jinými slovy, to, že entita někam nebo někomu patří, dotyčné vrstvě nedává právo s entitou manipulovat. Udělal bych to naopak. Sice jako lidé říkáme, že "článek patří do kategorie X", ale v programu pak načítáme kategorie DO článku, naopak, než jak to říkáme. Article.getCategories() málokdy Category.getArticles() To je spíš úkol nějaké ArticleRepository.fetchArticlesByCategory() A vracím se obloukem na začátek: Stejně tak sice "položky leží ve skladě", ale proč nevložit sklad do položek, jakkoliv to lidsky zní divně? Svázat je se skladem vazbou 1:1 a sklad mít jen jako jednoduchou třídu s ID, adresou, GPS souřadnicemi a aktuální zaplněností.

rezervace je změna stavu položky, a to není úkol skladu, ale položky samotné

ale sklad je spravcom polozky. rezervacia sama o sebe nema ziaden vyznam. rezervacia znamena ze sklad urci ze s danym predmetom nemoze byt manipulovane. a sklad to vie. to ze to vie polozka je nepodstatne. rezervacia je vonkajsi stav mimo predmetu. ja ako sklad mozem presuvat "rezervovanu" polozku kam chcem ak neviem ze je rezervovana. ja ako sklad sa nebudem pytat polozky ci s nou mozem manipulovat. sklad je tu ten kto riesi vnutornu logiku domeny.Priklad s clankom a kategoriami tu nefunguje kedze fyzicky produkt/polozka moze byt iba na jednom mieste v jeden cas, kdezto kategoria je iba label/tag ktory sam o sebe nema moc logiky, ak vobec. V priklade som schvalne hovoril o katalogu a nie kategorii.Co pises na konci je presne moj zaver, ze technicky moze iba polozka riesit svoj stav lebo objekt skladu nemoze mat v sebe vsetky polozky ktore v nom su..jedine ak by agregat skladu mal priame napojenie na repozitar poloziek a teda "boundaries" by boli zachovane, ale to mi pride trochu zavadazajuce riesenie. Preto to tu riesim lebo to nie je taky jednoduchy problem ako sa na prvy pohlad zda.--Este doplnim..naprikald ak ma byt polozka presunuta medzi dvoma skladmi, tak aktualny sklad kde je polozka musi tuto zmenu pripravit(napr. presun do vydajneho miesta, vytvorenie vydajky a/alebo prevodky, vyradenie z evidenice...) a potom cielovy sklad musi zase vediet prevodku spracovat a zaevidovat nove polozky. samotna polozka si nemoze diktovat ze sa ide presunut do ineho skladu. Zodpovednost za polozku ma sklad, nie polozka za sklad. Samozrejme moze drzat informaciu o tom v ktorom sklade sa prave nachadza, pre ucely propagacie eventov polozky, kde reaktory/projekcie nemusia zistovat v ktorom skalde polozka je s dodatocnymi requesmi, ale to je sucastou eventov napriklad ako cisto informacna vec.... inak som na tomto zaseknuty uz od piatku :D

rád bych ti poradil, ale tohle je příliš široké téma a ty pracuješ v nějakém svém světě a technologiích a chceš to na to napasovat, my ty tvoje omezení ale neznáme nebo mi z tvých příspěvků neplynou.Tohle je popsané v základech datového modelování a normalizace/denormalizace dat, problém ohledně nadřazenost/podřazenosti entity je disciplína objektového programování a základních návrhových vzorů, ne vždy to tak ale musí platit a světy jsou různé. Návrh od Martina je způsob jak se to běžně na webech/eshopech řeší.Ty jsi sám přiřadit skladu roli entitManagera a pak ti to dělá určité problémy, sklad ale může být pouze atribut, N:M vazba či cokoliv jiného. Sklad, rezervaci může řešit kdokoliv, záleží striktně na tvém logickém modelu a na způsob jak daný kód řešíš, v OOP je běžné, že akce s položkou, tj. její změny náleží třetí straně, která má k dispozici všechny údaje a vyhneš se problému typu, že sklad musí znát všechny položky nebo položka musí znát všechny sklady atd.Tohle vlákno je příliš teoretické a chceš poradit konkrétně, napiš sem tvůj současný návrh, poskytni tvůj současný kód, popiš co přesně s čím děláš. Bez toho to je akademická diskuze, kterou vést můžeme, ale nikam se s ní nedostaneš.

Tak som na to konecne prisiel ked som si spomenul ako som riesil sluzbu pre validaciou emailov kde api call na externu sluzbu prebiehal, samozrejme, mimo agregatu. Takze (mikro)sluzba je vlastne domena a sklad aj polozka, pripadne dalsie entity, su samostatne agregaty ktore su len prelinkovane id-ckami. Problem logiky ktory som riesil bol ten ze som ju chcel mat v agregate, lenze ta logika musi byt mimo agregatu nakolko ona iba riadi akcie(vytvara commandy) ale zmenu stavu(state) si meni kazdy agregat sam, o tom su tie boundaries.Cize riadiaca logika je uzavreta v ramic domeny, ale zmena stavu je uzavreta v ramci agregatov. Islo len o uhol pohladu(chybal mi nadhlad).