Správičky 2 823 Blogy 948 Fórum 18 796

Prehľad diskusie

photo
Spigi
Liero
10.5.2018 17:02:55
photo
RE: Spigi
siro
12.5.2018 13:29:55
photo
RE: Spigi
T
18.5.2018 9:26:10
photo
RE: Spigi
liero
18.5.2018 10:43:42
photo
RE: Spigi
liero
29.8.2018 13:47:56
photo
RE: Spigi
.
30.8.2018 1:20:51
photo
RE: Spigi
liero
30.8.2018 17:09:56
photo
RE: Spigi
siro
30.8.2018 20:00:18
photo
RE: Spigi
.
30.8.2018 21:21:17
photo
RE: Spigi
liero
4.9.2018 13:09:17
photo
RE: Spigi
vlko
5.9.2018 9:42:18
photo
RE: Spigi
Liero
10.9.2018 9:29:35
photo
RE: Spigi
spigi
10.9.2018 9:56:09
photo
RE: Spigi
Liero
10.9.2018 12:05:15
photo
RE: Spigi
Liero
11.9.2018 13:35:01
photo
RE: Spigi
spigi
11.9.2018 18:41:50
photo
RE: Spigi
T
11.9.2018 22:22:28
photo
RE: Spigi
vlko
11.9.2018 23:15:32
photo
RE: Spigi
T
12.9.2018 8:29:08
photo
RE: Spigi
Liero
12.9.2018 11:38:42
photo
RE: Spigi
Liero
12.9.2018 13:32:39
photo
RE: Spigi
T
12.9.2018 20:29:49
photo
RE: Spigi
Liero
13.9.2018 9:26:24
photo
RE: Spigi
Liero
13.9.2018 9:44:57
photo
RE: Spigi
T
13.9.2018 12:25:42
photo
RE: Spigi
Liero
13.9.2018 14:19:15
photo
RE: Spigi
T
13.9.2018 20:56:11
photo
RE: Spigi
Liero
14.9.2018 9:32:32
photo
RE: Spigi
T
14.9.2018 18:35:44
photo
RE: Spigi
siro
16.9.2018 9:04:50
photo
RE: Spigi
Liero
16.9.2018 10:16:08
photo
RE: Spigi
T
16.9.2018 13:37:31
photo
RE: Spigi
Liero
16.9.2018 17:50:39
photo
RE: Spigi
T
16.9.2018 20:37:32
photo
RE: Spigi
Liero
17.9.2018 9:13:10
photo
RE: Spigi
T
17.9.2018 11:57:08
photo
RE: Spigi
Liero
18.9.2018 10:23:28
photo
RE: Spigi
Liero
18.9.2018 10:39:30
photo
RE: Spigi
T
18.9.2018 16:31:26
photo
RE: Spigi
Liero
19.9.2018 9:55:23
photo
RE: Spigi
Liero
19.9.2018 10:13:02
photo
RE: Spigi
T
19.9.2018 23:45:02
photo
RE: Spigi
T
19.9.2018 23:48:29
photo
RE: Spigi
Liero
20.9.2018 11:01:07
photo
RE: Spigi
T
21.9.2018 19:10:28
photo
RE: Spigi
Liero
22.9.2018 16:25:25
photo
RE: Spigi
T
22.9.2018 23:02:47
photo
RE: Spigi
T
22.9.2018 23:17:18
photo
RE: Spigi
vlko
25.9.2018 9:14:10
photo
RE: Spigi
Liero
25.9.2018 13:06:27
photo
RE: Spigi
Liero
27.9.2018 10:38:51

Spigi

photo
Liero
10.5.2018 17:02:55
Body: 9780
Najaktívnejší č.: 6

Spigi

Pls, Poviete niekto, @Spigimu, nech to tu administruje, alebo nech odovzda kluce od miesacky niekomu, kto to moze robit?

Ja som uz davno od neho pytal pristup k DB aby som mohol zmigrovat vyvojari.sk na novu verziu, ale neodpovedal

[Reakcia]

photo
siro
12.5.2018 13:29:55
Body: 6920
Najaktívnejší č.: 7

RE: Spigi

Na Facebook mu napíš...

Š#iro

[Reakcia]

photo
T
18.5.2018 9:26:10
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

@liero: a nechcel si to prekodovat povodne ;-) (ze doniest miesacku a len si vypytat povolenie napojit sa na elektro?) :-D

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
liero
18.5.2018 10:43:42
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

No ved ja to uz mam viac-menej prekodovane. Chcem zmigrovat data.

[Reakcia]

photo
liero
29.8.2018 13:47:56
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

nemate na neho niekto cislo? Uz ma vazne hneva

[Reakcia]

photo
.
30.8.2018 1:20:51
Body: 2785
Najaktívnejší č.: 14

RE: Spigi

@liero: Mail nestaci?

i.stanek at chastia.com

 

[Reakcia]

photo
liero
30.8.2018 17:09:56
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Tam som mu pisal, neodpisuje

[Reakcia]

photo
siro
30.8.2018 20:00:18
Body: 6920
Najaktívnejší č.: 7

RE: Spigi

Možno by bolo dobré mu napísať cez FB....

Š#iro

[Reakcia]

photo
.
30.8.2018 21:21:17
Body: 2785
Najaktívnejší č.: 14

RE: Spigi

Pripadne skus nejaky z kontaktov http://chastia.com/Company/Contact.aspx (sekretariat, tel. podpora) - ak sa uz nedostanes po priamy kontakt tak mu aspon mozes nechat kontakt.

 

[Reakcia]

photo
liero
4.9.2018 13:09:17
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@Siro: tak mu skus napisat na FB, mne neodpisuje.

 

(.): jaj mam na neho email, kde som v minulosti s nim komunikoval, ked bolo treba nieco porobit na tomto portali, ale neodpisuje

[Reakcia]

photo
vlko
5.9.2018 9:42:18
Body: 37810
Najaktívnejší č.: 1

RE: Spigi

By som si tipol, ze je na dovolenke. pockaj este tyzden.

[Reakcia]

photo
Liero
10.9.2018 9:29:35
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@vlko:

nenasiel by si v starych maloch pristup na testovaciu databazu? Teraz mam chvilu casu doklepnut ten novy portal...

[Reakcia]

photo
spigi
10.9.2018 9:56:09
Body: 15965
Najaktívnejší č.: 3

RE: Spigi

Ahojte, 

liero, pozabudol som odpovedat na maily. Ako pisal vlko, najprv dovolenka, potom velmi busy.

Pred tym, nez cokolvek budeme kdekolvek presuvat, skusme si tu rozdebatovat, co chceme, ako to ma vyzerat, kto sa bude o to starat, kde je zaruka, ze sa starat bude apod. 

Tiez tie udaje v databaze mozme niekde zmigrovat, ale rad by som vedel kde. Co a kto teda konkretne chysta? Ako to vyzera?

Mozeme dat k tomu aj nejake pivko v BA a rozobrat to osobne. Kazdy tyzden som v BA aspon 1-2 dni. Liero, si lokalita BA? Vlko, Ty sa kedy vyskytujes v BA?

Dik. 

s.

PS: Na toto vlakno som si spravil v Outlooku pravidlo, aby som videl odpovede. Tak prosim pisme tu. Emailov mam denne niekolko desiatok, tak aby nezapadlo. 

Ing. Igor Stanek
CEO, Software Architect - CHASTIA s.r.o.
---
Chceš blogovať na tomto webe? Mať blog s adresou http://blog.vyvojari.sk/TVOJNICK?
Ozvi sa mi a tento blog Ti vytvorím.

[Reakcia]

photo
Liero
10.9.2018 12:05:15
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@Spigi: Vdaka za odpoved.

Takze postupne:

  1. co chceme:
    novsi design, podpora smartphonov, ochrana proti spamu, editacia prispevkov

  2. ako to ma vyzerathttps://vyvojari-sk-test.azurewebsites.net/ - je to starsia verzia, ale design tam je. MVP v podstate to kopiruje dnesnu funkcionalitu. Chyba este vyhladavanie a notifikacie.
  3. kto sa bude o to starat, kde je zaruka, ze sa starat bude apod.
    Kludne aj ty ak chces. Inak ja. Je to open source na githube, takze ktokolvek moze prispiet

  4. mozeme zmigrovat, ale rad by som vedel kde.:zatial chcem len napisat migracne skripty, takze len lokalne. Kludne aj anonymizovana databaza, ide mi hlavne o schemu. Inak by to malo bezat v Azure Database (PaaS), ak sa mi podari vybavit sponszorovany subscription.

Ja som v BA stale, nemam problem.

[Reakcia]

photo
Liero
11.9.2018 13:35:01
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Inak cudujem sa tvojej starosti o to, kto to tu bude spravovat, kedze zjavne teraz to tu nikto nespravuje. Mozno s vynimkou umiestnovania reklamy

[Reakcia]

photo
spigi
11.9.2018 18:41:50
Body: 15965
Najaktívnejší č.: 3

RE: Spigi

Ahoj, 

 

1. OK, chapem

2. OK, chapem. Problem vidim v migracii udajov - najma loginov, blogov. Toto nie je vobec jednoduche. To je na osobne stretnutie. 

3. Moja starost o spravu je opodstatnena. To, ze nemam cas aktivne spravovat web je pravda, ale minimalne bezi uz 16 rokov a upozornujem - STALE BEZI je nieco, co nie je bezne. Uz tu bolo mnozstvo portalov, ktore napriek velkej snahe vykapali - spominam si napr. na debug.sk a pod.

To, ze su tu bugy, spam (to by sa dalo relativne rychlo vyriesit) je dane "vekom" kodu.

4. Migracia by v tomto pripade bola potreba. Ale predtym, ako komukolvek poskytnem udaje, chcem mat istotu, ze bude zabezpecena migracia - bez nutnosti zasahu uzivatelov, aby sa nadalej vedeli nalogovat a aby nebol vypadok. To je presne to tom "starani sa". Kde je garancia, ze napriek Tvojej, alebo kohokolvek aktualnej snahe, Ta ta snaha neprejde o pol roka. Cim nenegujem tuto snahu a som za nu rad :).

K migracii este. Pozor, su tu casti kodu z roku 2002 a .NET 1.0, takze aj DB schema je dost komplikovana a narocna na migraciu. Nehovoriac o tom, ze 80% DB je schema z produktu, ktory sa volal Community Server pred viac ako 10 rokmi a ktory som malicko ohol, aby to tu bezalo a existovali jednotne loginy pre blogy a samotny web. Tento produkt medzicasom zanikol. 

Takze navrhujem osobne stretko, ale vidim to tak cca o mesiac. Do konca septembra nemam sancu. 

Ing. Igor Stanek
CEO, Software Architect - CHASTIA s.r.o.
---
Chceš blogovať na tomto webe? Mať blog s adresou http://blog.vyvojari.sk/TVOJNICK?
Ozvi sa mi a tento blog Ti vytvorím.

[Reakcia]

photo
T
11.9.2018 22:22:28
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

tiez len nazor

1. @liero: ciele su dobre, tieto v podstate naplnene, design aj ked som nevidel este s udajmi vyzera naozaj lepsie....ja by som ale jeden ciel pridal, a rovno poviem, ze ten naplneny nie je - lahka udrzatelnost a prispievanie ku kodu. Kod je sice pisany prehladne, ale ten event sourcing a "ponatie cqrs" tam vnasa len neporiadok a pre vacsinu ludi tipujem to bude showstopper, aby nieco dorobili. Uplne zbytocna aplikovanie a navyse v mnohych smeroch zle. Najmarkantnejsie....na jednej strane pracne oddelene C a Q  ale separacia C a M, ktora je dolezitejsia tam nie je(v action hanleroch sa generuju eventy...).  Co vobec nechapem napr. pouzitie membus, synchronizacia spracovania cez dobehnutie denormalizeru (co je uplne popretie zmyslu takto sepaorvat C a Q) , query model urobeny ako relacny.(keby bolo command model bez es a relacny, to by som este uplne chapal, ale query model, ktory plni nieco co sa vola "denormalizer" a ktory ma relacie je mimo moj vesmir chapania). ale to tu nechcem rozoberat. Super iniciativa, kopa energie a zabite snahou aplikovat nieco, co nemam nacvicene a nemam v tom uplne jasno a vobec sa na takyto projekt nehodi a vacsina z publika potencialnych prispievatelov sa v tom strati. Nechces to revertnut kym sa da?

2. @spigy, o tie blogy sa bojim aj ja a nie je mi jasne, ako sa to da premigrovat...myslim, ze nijako....posledne roky tam velmi hodnotny content nepribudal a ten stary je ...stary....a blogovat sa mi v hentom engine naozaj nechce...je to neskutocne pracne, skarede...cize toto by som kludne nechal zakonzervovane a zacal na bude 0.

3. @liero Neviem posudit uplnost implementacie, pozeral som to zbezne...@liero mas to uz 1:1?

4. @liero, ak to spustis na separatnej domene alebo "subdomene", ja sa kludne zapojim do nejakeho demo pouzivania. Ak urobis nejako lepsie/jednoduchsie blogy, kludne obcas niecim prispejem...podla mna mozes zacat aj bez migracie a myslim si, ze nas takych bude aj viac. Migracia je strata casu...mozno spravicky...mozno ale fakt len mozno fora...

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
vlko
11.9.2018 23:15:32
Body: 37810
Najaktívnejší č.: 1

RE: Spigi

Podla mna ak sa to ma niekde pohnut treba urobit tieto veci:
1. zmigrovat ucty teda login/overovaci algoritmus v_old
2. locknut stary portal na updaty a teda zachovat routovanie na vyvojari.sk/Forum, vyvojari.sk/News*, stare blogy zachovat na adrese blog.aspnet.sk
3. vytvorit novy portal tak aby linkoval na nove spravicky/blogy/forum
4. start from scratch, pripadne nejak spristupnit tie stare linky na novych strankach

Osobne mne cely nova verzia pride zbytocna, nahodil by som tu discourse + nejaky ghost na blogy. Tento portal ma ale iny problem, nie su ludia a to nijaky redesign/rewrite nevyriesi:)

[Reakcia]

photo
T
12.9.2018 8:29:08
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

@vlko: aj takto to dava zmysel...

problem bol aj ten community server blog...mna osobne do silne odradzalo...a chcelo to vela sabazprenia nieco publikovat...zasadne to ale novy portal nezmeni...ale mozno ked bude vyzerat modernejsie, pritiahne nejakych ludi aby sem prispeli napr. do fora.

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
12.9.2018 11:38:42
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Sample Data:

kliknite na zalozku sample data a generate all events. Naplni to portal datami.
 

Blogy:

neplanujem pisat vlastnu blogovaciu platformu. Zatial sa daju vlozit iba odkazy na blog, cize myslienka je taka, ze stare blogy ostanu bezat tam kde su, pripadne mozem zvazit nejaku readonly migraciu.
Zvazujem aj moznost mat vyvojari.sk ako Identity Provider, takze na externych blogoch by sa dali pouzivat vyvojari.sk ucty, ale nema to u mna vysoku prioritu.

Uplnost implementacie:

Kym to pojde do produkcie, je tam este vela veci, napriklad spominany routing, treba aj optimalizovat CSS, obrazky, cache a podobne veci., ale teraz je to v stave, ze sa mi neoplati na tom dalej pracovat pristupu k starej verzii.
 

Co sa tyka ES:

nemam problem, aby to niekto prekodil a mozem poskytnut navod, ale ja mam ine priority. Je to len moj experiment, no daval som pozor na to, aby sa to dalo lahko zmenit.
 
Len vysvetlim sucasny stav:
  1. Chceli sme mat historiu, ktora je podla mna potrebna, ked chceme mat editaciu

  2. Ukladat eventy + pisat denormalizery je pre mna rovnako vela roboty ako ukladat do normalizovanej databazy + pisat db views, ktore by vytahovali aktualne data z historie. Napriklad taky db view "Posledna aktivita" by sa mohol riadne skomplikovat a riesenie by pravdepodobne bolo vytvorit novu tabulku "Posledna aktivita", cim sa ale poprie zmysel

  3. Keby to nebol ES, tak by to bol zrejme CRUD pisany v controlleroch a ziaden DDD. Nemalo zmysel to komplikovat nejakym domenovym modelom. Tento "pattern" sa tusim nazyva Historical CRUD. 

  4. Rovnako nema v tomto pripade zmysel mat asynchronne commandy - neprinieslo by to ziaden realny benefit.
    Mam rozrobeny este jeden refactorig, kde by controller pri POST necakal na denormalizer, ale queries by cakali ten svoj denormalizer.
    *  prekvapuje ma ze @T tvrdi, ze zmysel CQRS je v asynchronite C a Q. CQRS to umoznuje, ale nieje to v definicii ale nieje to podmienka a urcite nie zmysel, vid napr:  Nights March 2016 Martin Fowler - Event Sourcing - asynchrony

  5. Event schema je zvycajne jednoduchsia a citatelnejsia ako DB schema, specialne ked podmienkou je historia.
  6. Event Bus mi umoznuje napriklad velmi transparentne invalidovat nacachovane partial views, alebo inu cache.
    Priklad: Url k fotkam userov som pridal do cache, inak som mal N+1 queries. Cache jednoducho invalidujem attachnutim sa na AvatarChanged event, pripadne ju rovno updatnem v pamati. Podobne je to s cachovanim partial views ako "posledne prispevky vo fore", "posledna aktivita", pocet komentarov atd...

  7. Event driven architektura je celkom handy, ked treba implementovat veci, ako posielanie notifikacii, pocitanie bodov, ziskavanie nejakych achievementov, typu - editovat prispevok moze iba uzivatel, ktory ma urcity pocet bodov atd.
    Novy event handler do Command modelu alebo denormalizer do Query modelu a je to. Inak by tato logica zrejme skoncila vsetka v controlleroch, pripadne v nejakom transaction scripte.

  8. InMem bus je tam len preto, ze tam je zatial InMemory databaza. Je to len zalezitost konfiguracie, ktoru rozhodnem, ked budem vediet, kam to budem deployovat.
To len na vysvetlenie, preco to je tak ako to je, netvrdim, ze to tak musi byt. Je to najjednoduchsia mozna varianta Event Sourcingu (bez DDD a bez asynchronity), ktora naozaj nieje komplikovana v porovnani s tradicnym pristupom. V takomto jednoduchom prevedeni benefity vyvazili cenu. Kazdopadne toto je len zlomok celkoveho effortu.

[Reakcia]

photo
Liero
12.9.2018 13:32:39
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@Spigi:

ved ja som ten kod uz videl, cosi som tu aj robil, aj DB access som uz mal. Mozes mi spravit kopiu databazy, kludne zatial vymaz/anonymizuj userov a hesla nech sa do toho konecne mozem pustit. Cas mam teraz, nie o mesiac. Uz mam chut sa na to vykaslat

[Reakcia]

photo
T
12.9.2018 20:29:49
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

pokracujem off topic, ale ok.

1. pri vybranych veciach a da sa to riesit klasicky versioningom v jednej tabulke, extra tabulke...ja neriesim auditovatelnost  ale len historiu a to len pre vybrane entity. Cize nariadit celoplosny postrek komarov kvoli dvom, co mas v spalni moze byt hlupe. 

2. Pri velmi jednoduchom projekte s jednoduchymi views, v tomto projekte je to skoro 1:1...posledna aktivita -> nic ci nebrani si logovat do separatnej tabulky a denormalizovat to, co je ucelne aj bez ES a denormalizerov. (toto je ale naozaj pekny UC pre domenove eventy a denormalizer...btw. domenove eventy nutne neznamanaju ze command model musi byt es)

3.DDD - principy DDD maju zmysel takmer vsade, domenovy model v zmysle old school DDD tu velky zmysel nema...nie je tu takmer ziadna business logika...

ale oddelenie aplikacnej logiky od prezentacnej, hoci jednoduchym transaction scriptom("services") aj na takomto projekte opodstatnenie ma (= oddelenie (M od VC))

, ovela ovela vacsie ako delenie C a Q...

4. asynchronne commandy zmysel nemaju pri takomto projekte, ale este menej nedava zmysel pouzitie architektury, ktora vychadzala prave z predpokladu ich nasadenia...a potom ich nezmyselne synchronizovat cez dobehnutie konkretneho denormalizeru. 

Este inak / ak volim nejaku architekturu, musim vediet zdovodnit jej ucelnost/vhodnost. Potrebou synchronnosti popieram ucelnost/vhodnost zvolenej architektury.

5. To je nezmysel. Komplexita a citatelnost je nutne komplementarna a specialne pri takomto projekte. Samozrejme zalezi, ako robis relacny model. A code first nie je rozhodne to najlepsie na manageovanie komplexneho relacneho modelu. (ak vychadzas z takehoto predpokladu)
Jedinou vynimkou je pripad, ak mam semistrukturovane udaje, ale tam sa pojem "model" straca zmysel ale to nie je tento pripad. Tu mam krasne strukturovane udaje bez akejkolvek variability.

6. Ano, to je jedno z peknych pouziti ale je otazne, ci je to najlepsia strategia cacheovania pri taktomto projete a ci ta komplexita, ktoru si tymto vniesol je primerana prinosu (nie je)

7a) Event driven != Event sourcing

7b) Denormalizovane to mozes ukladat aj pri primarne relacnom modely ak je to len nejaka marginalna cast riesenia. Ano v takomto pripade to skonci niekde v transaction scripte ale to same o sebe nie je nutne zle (skaredsie, horsie) pri tomto konkretnom projekte. Btw. z transation scriptu si mozem kludne fireovat domenove eventy a mat na ne zavesene denormalizery a mat command model releacny. Aj takyto variant implementacie CQRS existuje.(to len na okraj)

8) konfiguracie? cize len zmenis nieco v .config a zrazu tam bude nejaky bus ktory zarucuje bezstratovost? Ano chapem, ze sa to da prerobit a nebude to moc prace. Ale vidis, mas tam zbytocne technologicke issue, nevies kde to nasadis, nevies co bude k dispozicii, vies, ze to budes musiet prerobit...s cistou relacnou databazou by si mal o problem menej. 

2011 Rinat

https://abdullin.com/post/when-not-to-use-cqrs/ 2012

  • Strategy explains how to wage a war. DDD is one of the viable strategies in software war and it is particularly good in dividing and conquering complex domains.
  • Tactics deals with winning a battle (there could be a lot of these in a war). CQRS is a flexible software tactics that is particularly fit for the DDD strategy

Obviously, you can try to take CQRS patterns and apply mechanically to any system. Sometimes this might work and sometimes this might be as awkward as using SQL Stored Procedures for business logic. 

Don't use CQRS in your system, if you have more important things you can do first. 

Udi 2011 http://udidahan.com/2011/04/22/when-to-avoid-cqrs/

Martin 2011 https://martinfowler.com/bliki/CQRS.html

Despite these benefits, you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base that is updated in the same way that it's read, adding CQRS to such a system can add significant complexity. I've certainly seen cases where it's made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team. So while CQRS is a pattern that's good to have in the toolbox, beware that it is difficult to use well and you can easily chop off important bits if you mishandle it.

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
13.9.2018 9:26:24
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@T: pozri sa, ked ta to tak irituje, sprav si novy branch, navrhni tam databazu a sprav aspon jeden controller. Zvysok dorobim. 8) Pouzivam tam kniznicu Rebus, ktora ma adapter na prakticky kazdy message bus (Azure Service Bus, RabbitMQ, MSMQ, SQL....), cize je to jeden riadok kodu. 3) Principy DDD su tu vyjadrene domenovymi eventami, ktore predstavuju ubiquitous language. Transaction Script je trivialne dorobit ad hoc, len teraz v kontroleroch naozaj nieje ziadna ina logika, len savnutie jedneho eventu. Odabstrahovat toto inej vrstvy by malo aky zmysel? Ak v controlleroch bude viac logiky, samozrejme sa to dorobi. Lenze dalsia logika bude v EventHandleroch, ktore mozu teoreticky produkovat dalsie eventy typu: UserMentioned, BadgeReceived, NotificationSent... 4) Suhlasim, ze je nezmyselne mat async commandy, synchronizovane cez dobehnutie denormalizeru. Toto sa nepaci ani mne. Zial neskoro som zistil, ze Rebus nema ziadne API na synchrony messaging. Ale presne kvoli tomuto som to robil, aby som prisiel na taketo veci. No ono tam predsa len nejaky zmysel je. Ja totizto cakam iba na jeden denormalizer, ktory potrebujem na spravne zobrazenie vysledku (po redirekte). Nemusim napriklad cakat na ActivityDenormalizer, pripadne nasledny workflow (notifikacie, maily, bodovaci system...). Zo synchronnym messagingom by to bol trochu problem. 5) Takze, relacna databaza by v tomto pripade vyzerala ako tabulky Content+ContentTypes, pripadne komplikovanejsia verzia s ContentFields+FieldTypes. Ked sa pozriem na takuto schemu, tak nevidim nic. Cize ak by som to chcel spravit aspon trochu expresivne, tak budem musiet nejakych sposobom vyjadrit v kode to, co som vyjadril mojou eventovou schemou, ci uz pomocou Commadov, Transaction Scriptu etc.. Inak suhlasim skoro zo vsetkym, co si povedal, len (relacny model + verzie contentu v relacnom modely + denormalizovane tabulky + domenove eventy) mi nepride jednoduchsie ako ES.

[Reakcia]

photo
Liero
13.9.2018 9:44:57
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@T: pozri sa, ked ta to tak irituje, sprav si novy branch, navrhni tam databazu a sprav aspon jeden controller. Zvysok dorobim.

8) Pouzivam tam kniznicu Rebus, ktora ma adapter na prakticky kazdy message bus (Azure Service Bus, RabbitMQ, MSMQ, SQL....), cize je to jeden riadok kodu.

3) Principy DDD su tu vyjadrene domenovymi eventami, ktore predstavuju ubiquitous language. Transaction Script je trivialne dorobit ad hoc, len teraz v kontroleroch naozaj nieje ziadna ina logika, len savnutie jedneho eventu. Odabstrahovat toto inej vrstvy by malo aky zmysel?
Ak v controlleroch bude viac logiky, samozrejme sa to dorobi. Lenze dalsia logika bude v EventHandleroch, ktore mozu teoreticky produkovat dalsie eventy typu: UserMentioned, BadgeReceived, NotificationSent...

4) Suhlasim, ze je nezmyselne mat async commandy, synchronizovane cez dobehnutie denormalizeru. Toto sa nepaci ani mne a rad by som to zmenil. Zial neskoro som zistil, ze Rebus nema ziadne API na synchrony messaging. Ale presne kvoli tomuto som to robil, aby som prisiel na taketo veci.

No ono tam predsa len nejaky zmysel je. Ja totizto cakam iba na jeden denormalizer, ktory potrebujem na spravne zobrazenie vysledku (po redirekte). Nemusim napriklad cakat na ActivityDenormalizer, pripadne nasledny workflow (notifikacie, maily, bodovaci system...). Zo synchronnym messagingom by to bol trochu problem.

5) Takze, relacna databaza by v tomto pripade vyzerala ako tabulky Content+ContentTypes, pripadne komplikovanejsia verzia s ContentFields+FieldTypes. Ked sa pozriem na takuto schemu, tak nevidim nic.
Cize ak by som to chcel spravit aspon trochu expresivne, tak budem musiet nejakym sposobom vyjadrit v kode to, co som vyjadril mojou eventovou schemou, ci uz pomocou Commadov, Transaction Scriptu etc..

Inak suhlasim skoro zo vsetkym, co si povedal, len (relacny model + verzie contentu v relacnom modely + denormalizovane tabulky + domenove eventy) mi nepride jednoduchsie ako ES.

[Reakcia]

photo
T
13.9.2018 12:25:42
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

irituje...neirituje ma nic, len som sa Ti snazil napisat, ze z hladiska toho, ze to ma byt nejaka komunitna platforma to zbytocne podriadil nejaku svojmu experimentorstvu(mal si si vybrat jeden ciel, nie dva, ktore si protirecia)...to je v podstate vsetko podstatne...nerozumiem, aky controller mam pisat...kludne dopisem, ak to bude nejaka normalna architektura a budem v tom vidiet zmysel

8. ok

3.  "Principy DDD su tu vyjadrene domenovymi eventami, ktore predstavuju ubiquitous language"

co ma ubiquitous language spolocne s domenovymi udalostami? Domenove udalosti by mali byt v zmysle DDD pomenovane v ubiquitous language (tak ako commandy, entity a metody domenoveho modelu). To je jedina zmysluplna veta/reakcia, ktora sa na to da napisat.

"len savnutie jedneho eventu."

Toto jednak nie je pravda(a nebude, ak to dotiahnes)...ale ja som hovoril o inom...ze separacia C a Q je menej podstatna ako M a VC a specialne v tomto projete. Takze ano, ak je tak jednoduchy, ze sa neoplati separacia M a VC, tak s najvacsou pravedpodobnostou o to menej C a Q.

"Lenze dalsia logika bude v EventHandleroch, ktore mozu teoreticky produkovat dalsie eventy typu: UserMentioned, BadgeReceived, NotificationSent..."

Moze, ak by to ako v tomto pripade nebola uplna marginalita, ktora sa da obkodit aj inak. Pouzit kanon na vrabce, zase nieco, v tom sa bezny clovek strati (chces to spristupnit davom, vsak?).

A to o com pises je skor nastroj na korelaciu a aggregaciu udalosti ako "event handler"....v nservicebus sa na to (obe veci) pouzivaju sagy (potrebujes mat spolocny kontexte a vediet spracovat nejaku postupnost eventov), event store ma dokonca jednoduchu CEP(complex event processing) engine, ktore sa na to standardne pouzivaju.

"Ja totizto cakam iba na jeden denormalizer, ktory potrebujem na spravne zobrazenie vysledku (po redirekte)."

Ved ja vidim, co robis. Na toto ta architektura nie je. Riesit sa to da tak, ze zobrazis po submite hlasku a user si pocka, kym sa to, co odoslal zobrazi.(napr.)

4.  Ale to nie je o synchronnom messagingu. To je o tom, ze mas zlu architekturu, ak si sam uvedomujes, ze ovela praktickejsi by bol v tomto pripade sync pristup. A spracovanie commandov (synchronne) vs. asynchronne spracovanie je jedna vec. Druha vec je eventualna konzistencia. Ty mas zjavne problem s tou druhou vecou, lebo commandy spracovavas synchronne.(controller) To je ale predpoklad pouzitia takejto architektury. Ked sa nechces vysporiadavat s EC, tak urob iny(vhodnejsi) design.

5. celej tejto uvahe nerozumiem. Relacny databazovy model pre vyvojari.sk by vyzeral pekne a prehladne. Rovnako by vyzeral aj model eventov. "Content+ContentTypes" to fakt netusim, aky model by si v relacnej databaze robil Ty.

6. Maximalna primerana forma cqrs pre takyto projekt je jedna shareovana databaza pre C a Q a query model postaveny bud nad viewmi alebo kludne aj Linq to EF lebo queries su trivialne.

Commenty su asi jedina vec, ktoru treba verzionovat. (mozno clanok, mozno blog post ale to asi ani nikto neocakava)...cize jedna z 50 entit/agregatov aj to je otazka, ci chcapat comment ako aggregat root. Takze v relacnom modely jedna tabulka s historiou....verzus cela ES/CQRS komplexnost.(navyse ak by som ju chcel mat vsade, tak si spravim jeden interceptor na urovni datoveho pristupu a ani neviem, ze taku historiu logujem)

 

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
13.9.2018 14:19:15
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Myslel som, ze mozes na nejakej casti portalu (napr spravicky) ukazat, ako by si to robil a ja potom podla toho prerobim zvysok. Mas ten luxus, ze funkcne je portal takmer hotovy, presne vies ako budu vyzerat views, atd...

Co sa tyka relacnej databazovej schemy (5), ked das kazdu entitu do osobitnej tabulky ako budes robit napr fulltextove vyhladavanie? Query na kazdu tabulku? Taketo CMSka zvycajne ukladaju vsetok content do jednej tabulky a nemaju klasicku relacnu databazu.

 

A nerozumiem tomuto: "" v controleroch je len savnutie jedneho eventu." - Toto jednak nie je pravda(a nebude, ak to dotiahnes):
Co nieje pravda? Co ine tam este robim? Ak tam nieco pribudne, tak sa tam dorobi to M, bud ako TS, alebo inak, ale v sucasnom stave neviem co ina ako ten SaveEvent sa da odtial vytiahnut.

 

"ze separacia C a Q je menej podstatna ako M a VC a specialne v tomto projete. Takze ano, ak je tak jednoduchy, ze sa neoplati separacia M a VC, tak s najvacsou pravedpodobnostou o to menej C a Q."

Tu si dovolim nesuhlasit. Kedze aspon zatial business logika ne skoro nulova, hodnota separovaneho M je tiez skoro nulova. Ale zo separacie C a Q benefitujem stale. Napriklad Eventy som si definoval uplne na zaciatku, hned potom aj ich vytvaranie v POST metodach controllera a odvtedy sa to prakticky nemenilo. No Query model menim stale, napriklad ked mi grafik dal grafiku a vlozil tam view "posledna aktivita", alebo teraz ked robim fulltextove vyhladavanie.

Kazda takato zmena by si bez CQRS vyziadala viac refactoringu aj v command aj v query casti. Takto prakticky menim iba query cast.

[Reakcia]

photo
T
13.9.2018 20:56:11
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

@liero:

teraz ale fakt neviem, co mam/v akom style dorobit? S tranzaction scriptom a relacnym modelom, a symbolickym rozdelenim C a Q(db view a dva EF contexty)...alebo uplne bez neho? (dorabat do niecoho existujuceho je niekedy narocnejsie ako zacat od zaciatku ... a druha vec, nemas to zakladne, databazovy model) ...spravicky,fora,clanky,commentare,blogy

" Co ine tam este robim?"

napr. kontrolujes opravnenia, staticky aj kontextovo(asi nechceme aby som mohol jano jozovi editovat spravicku, vsak)? kontrolujes existenciu entity?(=riesis kontextove validacie, ktorych sa najde casom urcite viac? Nejake hlasky userovi o vysledku operacie? Nebude  riesit error handling na urovni spracovania commandov? (asi nebudes, naco to sofistikovane logovat a userovi dat moznost cez nejake IDcko reportovat chybu)...atd.

....Fulltext...existuje x technik ako intelignetne riesit fulltext...pouzitie externeho indexovacieho engine(ktory si uklada indexy niekde vonku)

...trivialny materializovany view s fulltext indexom (v ms sql tusim nejde union pri indexed views, takze si musis vybrat poriadnu db)...

...a ano, kludne aj specializovana tabulka pre indexovanie...jeden insert naviac pri par entitach...nevidim problem...rovnaky pocet riadkov kody ako ked pises denormalizer, akurat tu je krajsie, ze to mas pokope.

"hodnota separovaneho M je tiez skoro nulova. Ale zo separacie C a Q benefitujem stale. Napriklad Eventy som si definoval uplne na zaciatku, hned potom aj ich vytvaranie v POST metodach controllera a odvtedy sa to prakticky nemenilo."

v momente, kde to prestane byt prototyp pochopis, ze sa mylis, vid. vyssie veci, ktorymi sa nezaoberas a ktore Ti vnesu do tych kontrolerov komplexistu ....

"No Query model menim stale, napriklad ked mi grafik dal grafiku a vlozil tam view "posledna aktivita", alebo teraz ked robim fulltextove vyhladavanie."

...vies si view dorobit kedykolvek aj pri relacnom pristupe...nechas pregenerovat ef context a uz aj queryujes....a to bez nutnosti prehravat eventy, aby sa ti denormalizovali udaje a ladit denormalizer....ja robim default separaciu C a Q aj pri releacnom modely ale uplne jednoducho (jeden EF context commnad, druhy nad viewmi query), v tomto zmysle to povazujem za uzitocne aj na takto malom projekte, ale neviem, ci by som do toho isiel pri nejakom komunitnom vyvoji, ked to nebude vacsine ludi davat zmysel. Pochop uz, ze ta denormalizacia dava zmysel pri velkych skalovatelnych riesianiach, pri pouziti (noSQL) technologii, ktore z toho vedia profitovat, pri pouziti aync spracovania....atd. nie v pripade relacnej databazy...kde mas query model relacny...akoze nerelacny command model transformujes na relacny query...to si doteraz nevysvetlil preco...

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
14.9.2018 9:32:32
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Taka separacia C a Q ako ty popisujes je len iluzia nejakej separacie.

Vid priklad z vyhladavanim: podla tvojho navodu mam robit dalsi insert navyse, pripadne externy indexovaci system, pripadne vymenit MSSQL za Oracle alebo co. Vsetko toto vyzaduje dost zasadne zmeny v command casti, tak o akej separacii sa tu bavime?

Iny priklad: Pridanie latest activity viewu by podla tvojho navodu (nova tabulka) znamenalo zmeny prakticky do celej command casti. Tak aka separacia C a Q?

"takze si musis vybrat poriadnu db" - aha, takze pre to navrhovane "jednoduchsie" riesenie a vhodnejsie pre komunitny vyvoj nieje ani MS SQL dobry. To bude naozaj radost vyvijat v porovnani s tym co tam je teraz - netreba ziadnu DB, vsetko vie bezat InMemory, na spustenie a zbuildovanie staci .net core sdk.


"teraz ale fakt neviem, co mam/v akom style dorobit?".

V akom uznas za vhodne. V Controleroch mas ViewModely na vstupe aj vystupe, vyhodis CommandStack a QueryStack projekty a vytvoris si vlastny relacny model.

Akurat by som sa rad vyhol Databazovemu projektu vo Visual Studio, lebo to pridava zavislost na Visual Studio a Windows. Momentalne to funguje celkom dobre aj vo VS Code aj na Macu.

[Reakcia]

photo
T
14.9.2018 18:35:44
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

"Taka separacia C a Q ako ty popisujes je len iluzia nejakej separacie. "

Naozaj? Mozno vo vztahu ku tvojej nespravnej predstave o CQRS. Tak si najpr zadefinujem pattern.

Command and Query Responsibility Segregation (CQRS) is a pattern that segregates the operations that read data (queries) from the operations that update data (commands) by using separate interfaces.

to je aplikacia patternu, ktora je primerana projektovym vychodiskam.(podla mna, mam to odskusane na n projektoch s podobnymi vychodiskami a roznymi technologiami) 
Vychodiska, ktore vnimam... (relacna db, bez ocakavania horizontalnej skalovatelnosti, komunitny vyvoj, zvacsa crudy, takmer ziadna business logika)....iluzia teda este v com? Ze mam dva modely/interfaces a pod nimi mam infrastrukturu ktora je efektivna voci tech. vychodiskam, ze aplikovanim tejto separacie na projekte ziskam (menej komplexnosti, produktivita)....nie stratim (vnesiem viac komplexnosti, zabijem produktivitu) ? Cielom CQRS je pomoct riesit problemy a formu musis prisposobit tomuto cielu...nie exhibicionizmu, ktory potom dopada vacsinou zle...(pattern vznikol pre riesenie komplexnych domen, kde aplikacia old school DDD pristupov pre implementaciu nefungovala, zabijala projekt komplexnostou, ktory vnasala a nereflektovala poziadavky na "big") 

ano, toto je presne taky sposob myslenia, ktory nikto pri CQRS vidiet nechce/nechcel. Naozaj treba aplikovat najkomplexnejsiu jej formu, aj ked z nej nemas ako profitovat, pouzijes technologie, ktore na nu tuto formu ani nie su vhodne, neovladas jej podstatne detaily, nemas na to projekt a dokonca ju ani nechces.(lebo eventualna konzistencia je pre Teba nieco nezelane podla kodu)...keby si si zo vsetkeho co som nalinikoval precital aspon ten Fowlerov clanok...krajsie ten zdvihnuty prst (kedy ano a kedy nie) ja nepopisem...Nie je lepsie zacat niecim jednoduchym a primeranym? ...a popritom citat...vela citat a premyslat?

"Vid priklad z vyhladavanim: podla tvojho navodu mam robit dalsi insert navyse, pripadne externy indexovaci system, pripadne vymenit MSSQL za Oracle alebo co. Vsetko toto vyzaduje dost zasadne zmeny v command casti, tak o akej separacii sa tu bavime?"

sorry, toto nema hlavu ani patu....NIKDY nebolo ambiciou CQRS vyriesit vsetky problemy ...to ziaden pattern nedokaze...riesi/pomaha riesit konkretny problem...a konkretne aky sa docitas na linkach...(komplexna domena...poziadavky na skalovatelnost)...jedna metoda, ktoru volam zo vsetkych miest, kde potrebujem nieco zaradit do toho centralizovaneho fulltext vyhladavania? To je fakt problem, ktorym obhajis zmysel volby zlej architektury. Mimochodom, je uplne bezne...ze fulltext riesis externou technologiou pri CQRS...je to uplne iny problem ako C a Q.(elastic, solr...)...jedina vynimka su db, ktore su postavene nad takymto engineom a maju fulltext implicitne k dispozicii (ravendb)....este inak C a Q a F su tri problemy a zvacsa sa ich oplati (na komplexnom projekte) riesit separatne. Tento je malinky, tak som Ti napisal, co povazujem za najefektivnejsiu formu.(pekne sa da vyrobit fulltext builder, ktory bude mat genericku metodu per entita napr. a bude zodpovedat za budovanie takejto ftabulky pre fulltext indexaciu a bude to rovnako pekne ako denormalizer...on to vlastne denormalizer je)

btw. insert naviac je nieco apriory zle? Taky isty insert ako robis Ty v denormalizeroch? Vlastne ty robis tych insertov viac, lebo si sa mne stale z neznameho dovodu rozhodol pre relacny query model ;-)

a tu sa odusevnujes nad tym, ze som Ti navrhol pouzitie inej databazy s nejakou mudrou vlastnostou (a nie, oracle som pri comunitnom vyvoji pred ocami nozaj nemal)....a Ty znasilnujes relacnu db na storovanie niecoho na co su ovela efektivnejsie no sql databazy a este si nedas ani tu namahu, aby si par nastaveniami ukladal udaje tak, aby si aspon trochu zmiernil limitacie(vypolo lockovanie napr. pri inserte)...pre komunitny vyvoj pouzijes drahu DB, ktora je aj vo verzi STD mrzakom, hoci mas niekolko free alternativ.

"V akom uznas za vhodne."

cize si to mozes nakodovat sam...okrem viewov nemam v podstate nic....tak? A viewmodely som nepozeral, ako si ich urobil. Videl som, ze query data lopatujes z controllerov.

Dabazovy projekt bol nahodou super, VS community je zadarmo, dokonca mame nieco podobne aj pre ine databazy....ale splnit tuto poziadavku by bolo najmenej....

ved sa kludne u nas zastav niekedy, ked bude klud a mozeme si prejst ako robime architekturu pre taketo projekty...to je asi najefektivnejsia forma...

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
siro
16.9.2018 9:04:50
Body: 6920
Najaktívnejší č.: 7

RE: Spigi

Nie je to zlé, keby sa trošku modifikoval dizajn (hlavne ten header, ostatok je v pohode), tak podľa mňa by to bolo dobré. Oceňujem, že @Liero sa do toho vôbec pustil a že to vôbec dokončil do ako tak finálneho stavu. Neveril som mu a osobne si myslím, že by sa to malo nejakým spôsobom použiť a pracovať na tom ďalej. @Liero nehádal by som sa s @T, lebo on sa bude s tebou hádať stále, on to má už roky rokúce v povahe. Kiež by ti radšej miesto písania pomohol alebo urobil niečo zmysluplné. Dôležitý je výsledok a ten ako som povedal, nie je vôbec zlý.

@Spigi osobne si myslím, že toto môže pomôcť aj tebe ako majiteľovi domény, pracujem už pomaly na konferencii CodeCon 2019 a ak bude nová verzia funkčná do konca tohto roka, tak tam budem túto stránku veľmi propagovať, pretože si myslím, že toto potenciál má. Ak to nenaučíme mladých ľudí, tak táto stránka bude už nenávratne stratená.

MIGRÁCIA DÁT:

Ja by som si s tým hlavu nelámal a urobil by som úplne novú DB. Starý content by som poslal na večný odpočinok aj so starými blogmi. Staré nikoho nezaujíma a verím, že aj návštevnosť poriadne klesla kvôli contentu. Veci čo boli "in" sú už dávno "out" a ak sa budeme držať starého ducha, tak nič sa nezmení.

@Liero v každom prípade dobrá práca!

Š#iro

[Reakcia]

photo
Liero
16.9.2018 10:16:08
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@Siro: "lebo @T sa bude s tebou hádať stále, on to má už roky rokúce v povahe"

ved to aj ja :) ale konfrontovat svoje nazory s inymi je vzdy uzitocne.

"keby sa trošku modifikoval dizajn, hlavne ten header" - povodne tam bol modry, podobalo sa to na stackoverflow, ale ja som chcel, aby to malo nejaku spojitost so sucasnymi vyvojarmi.

 

@T: cize si to mozes nakodovat sam.

Presne tak. Neviem preco ocakavas, ze vsetko budem robit ja... Ja uznavam ze Event Sourcing je v tomto pripade kanon na vrabce, ale funguje to celkom dobre a nevidim ziadnu pridanu hodnotu v tom ze to budem prerabat na nieco ine a uz obzvlast nie, ak by to malo zvysovat naroky na dev prostredie. No zaroven nikomu nebranim, aby to prerobil.

To ze tam nieje Mko a ze query lopatujem v controleri len ulahcuje robotu tomu, kto to bude chciet prerobit.

 

 

 

 

[Reakcia]

photo
T
16.9.2018 13:37:31
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

@siro: cisty offtopic a podpasovka...klasika...diskutovat (upozornit na nejaky problem) je nieco ine ako hadat sa. To je mozno Tvoja rovina uvazovania...aby som neoplacal malicherne, tak nenapisem ze roky...prist s niecim "genialnym" a nebyt schopny prijat konstruktivnu kritiku alebo iny nazor a reagovat jesitne ..ale dost sa cudujem, ze este po rokoch sa nevies zmierit s tym, ze na Tvojej ceste za "uznanim"(to bolo vzdy citatelne) Ti niekto napisal aj nieco(nebol som jediny, ze), co sa Ti nepacilo a nevedel si prijat a dodnes mu to zjavne nevies odpustit ...zdrhol si odtialto, pouzival si vyvojari.sk akurat na promo a linkovanie, zalozil si si svoj blog a postupne som Ti tam prestal chodit priznit blogy, kde je problem?....

mimochodom, ja som napisal aj pozitivne veci smerom k @lierovi...(a vzdy aj na margo Tvojich aktivit ak som ich videl)

..a pises, ze vysledok? Aktualne je to funckny prototyp(nemyslim to v zlom)...vysledok bude....niekolko rokov udrziavana stranka(ako pisal @spigy) a ak ma do nej prispievat nejaka skupina ludi(to bol deklarovany zamer, ktory sa mi paci), tak by to nemalo byt nieco architekturne "zle alebo komplikovane"...ta investovana energia mohla byt investovana lepsie (vo vztahu ku komunite)..to bolo vsetko podstatne, co som chcel napisat...zvysok diskusie je venovany CQRS...(o ktorom som uz diskutoval s Lierom v case zameru, ale nedal si poradit, teraz hodnotim " medzi" vysledok)...

@liero: ja nic neocakavam, okrem blogov viem zit aj s tym, co tu je. Bola to Tvoja iniciativa, ja som ju podporoval a podporujem. Krizitoval som a) nenaplnenie pre mna podstatneho ciela, aby mohli prispievat kodom dalsi ludia - zamer sa mi pacil ale nie vysledok a napisal som preco b) formu CQRS - cisto architekturna zalezitost a pokracovanie starsich diskusii, ked uz si sa napriek varovaniu o nevhnodnosti specialne ES pri tomto projektovom setupe na to podujal

liero "prerobit" = v tomto pripade nanovo nakodovat...hodit 80% Tvojej namahy do kosa. Pre mna by to bola cista rutina, mam ovela zaujimavejsie veci v stacku, ktorym sa potrebujem venovat. A urcite neurobim to, ze to postavim na hypergalaktickych technologiach, aby som si to vyskusal a malo to pre mna pridanu hodnotu. Vysledok neisty a aj keby bol dobry, pre vacsomu ludi neuchopitelny, mimo mainstream, ktory by mohol prispiet.

Prave naopak...bolo by nadherne ukazat bezpecnu architekturu, pattern pre takyto typ aplikacie...v asp.net mvc core...to by same o sebe okrem novej platformy dalo zacinajucim ludim dalsiu pridanu hodnotu...(ale zle aplikovane cqrs je presnym opakom)

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
16.9.2018 17:50:39
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

80÷ mojej namahy urcite nebolo ukladanie a queryovanie dat,to skor tych 20÷. Ked to nechces zahodit do kosa, tak preco ma presviedcas, aby som to prekodil ja? :) Nemyslim si, ze ten EventSourcing je realne nejaky bloker. Naopak, teraz je to super easy skompilovat a spustit Netreba ani deployovat databazu, ani nic instalovat, dokonca netreba ani visual studio, takze je to maximalne jednoduche. Tiez nechapem, ak je jednoduchost vyvoja cielom,preco ma kritizujes,ze som nepouzil NoSQL databazu. Nuz lebo by ju bolo treba instalovat, pravdepodobne by sa nedal pouzit EntityFramework,ktory kazdy pozna a ma InMemory provider. Nic by som tym neziskal a vyrazne by som stazil niekomu zacat prispievat

[Reakcia]

photo
T
16.9.2018 20:37:32
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

@liero: Ja Ta nepresviedcam, aby si to preprogramoval.(citaj pls). Ja len pisem, ze keby som sa do toho mal pustit ja(s tym si sa na mna obratil Ty), tak mi zostava 20% pouzitelneho kodu.(views - nemam db model, nemma queries voci relacnemu modelu, nemam tran script, controllery a view model musim prerobit)

Blocker(kde som to vrdil?) nie, zbytocna komplikacia/odradzujuci prvok ano. Jednoduchost - to iste by si dosiahol s ovela mensim poctom komponentov aj pri "klasickom" pristupe.(core + ef + ms sql...ale mozno radsej postgre...)

NoSQL - zase mimo, ja som hovoril o tom(citaj pls), ze ked si sa uz rozhodol pre CQRS preco si nepouzil NoSQL, ktora je prirodzenejsia, tu si znasilnoval MS SQL a znasilnil si ho navyse nedobre. (resp. preco si rovno nepouzil nieco na ES site napr. event store, ktory ma v sebe celu potrebu infra na C aj Q a je na toto naozaj efektivny...)

"pravdepodobne by sa nedal pouzit EntityFramework,ktory kazdy pozna a ma InMemory provider"

sorry, ale toto je zase cele take zbytocne zbrkle....a neverim, ze by si na to neprisiel aj sam....

1. A naco Ti je pri NoSQL databaze a specialne pri CQRS s ES...objekto-relacny mapper? (ak si odmyslim to uplne nezmyselne vnesenie relacneho modelu do Q casti)
nanic...nemas problem relacie v ramci agregatov, ukladas ich cele....a pouzivas z toho, co najdes v ORM len uplne okrajovu cast funcnosti...presne tu, ktoru ma v sebe napr. .... RavenDB klient (moznost queryovat cez linq, CRUD, schopnost serializovat objekt a ulozit, unit of work...)...

2. Napr. RavenDB.....EmbeddableDocumentStore { RunInMemory = true } 

3. Cast no sql databaz netreba instalovat...rovno je alebo vie to bezat ako nejake .exe, installer je zvacsa kvoly toolingu....alebo behu ako windows service

4. OK este pre istotu spat k ORM, problem relacii existujuce v no sql svete....vazby medzi agratmi...ale aj na to ma vacsina nosql slusnu podporu v ramci klientov....

P.S. a este raz k tej otazke EF....Tebe je vlastne naco EF v tomto projekte? V C casti uplne nanic, co z neho vyuzivas? V Q casti ak by si hodil do kosa ten ralacny model tak najvacsiu pridanu hodnotu ma linq provider....myslim sa?

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
17.9.2018 9:13:10
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Ach jaj, ty popries aj vlastnu matku aby vyhral argument.

"Ja Ta nepresviedcam, aby si to preprogramoval.(citaj pls)" Naozaj? Prvy komentar si ukoncil: "Nechces to revertnut kym sa da?" O com sa ty cely cas bavime potom?

"Blocker(kde som to vrdil?)" - Ked uz si nepamatas, co pises, tak aspon citaj po sebe: "pre vacsinu ludi tipujem to bude showstopper"

Ak tvrdis, ze by si musel zahodit 80% projektu, alebo zahodit 80% namahy, tak mam pochybnost ci vobes vies, co full stack development obnasa. Pre istotu citujem, keby si sa to zasa snazil popriet: "hodit 80% Tvojej namahy do kosa."

Mas to tam tak naservirovane, ze pohodlnejsie to uz ani nemoze byt.

  • Transaction Script tam ziaden nieje, takze nemas co zahodit.
  • ViewModel nemas preco prepisovat. Ak som tam aj pouzil DTO z querymodelu (nepamatam), tak by si to mal reusovat a namapovat 1:1 na DB View.
  • Mas presne definovane co maju DB views vracat
  • Mas presne definovane, co je na vstupe commandov
  • Ked budes mat views a transaction script, refactoring controllerov je tiez trivialny. Okrem toho, ziadal som ta iba o jeden controller

"Tebe je vlastne naco EF v tomto projekte" - pretoze sa mi neche pisat RAW sql commandy, nechcem zatial byt zavysli na kontretnej DB, lahko sa to deployuje, lahko sa to mockuje v testoch a vie to bezat inmemory aj bez DB enginu.

Anyway, uz som z tejto diskusie unaveny, takze ak nemas v umysle urobit nejaky contribution, ani sa neunuvaj odpispovanim

[Reakcia]

photo
T
17.9.2018 11:57:08
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

@liero: naozaj si detinsky teraz vypisujme, koho to viac unavuje a vacsinu energie venujes ad hominem, popritom neodpovedas na otazky, preskajues argumenty na ktore nemas odpoved, ohybas vyznamy...

Pisal som, ze vacsinu ludi, nie vsetkych (o com som presvedceny a keby si nachvilu mal dovod sa na veci pozriet z nadhladu a nie z tej pozicie, ze som to napisal ja) tak by si to uznal. A blocker pri prispievanie to nie je. To ma uplne iny vyznam / pre mna.(ze nemozu, nedokazu)

"tak mam pochybnost ci vobes vies, co full stack development obnasa."

:-) keby som nevedel, tak nepisem, ze 80%.

1. "Transaction Script tam ziaden nieje, takze nemas co zahodit."

fakt k veci, kedze sa bavime o tom, co sa da z existujuceho kodu pouzit, resp. kolko treba zahodit

2. ViewModel nemas preco prepisovat.

mam a hned niekolko....ale ten by MOHOL, keby som sa chcel podriat niecomu so sice nie je najkrasie, ale "robi sa to tak" z vacsej casti zostat, zaroven je v nom vsak minimum kodu.(je triavialny)

3. Mas presne definovane co maju DB views vracat

zase mimo, bavime sa o kode, ktory, treba hodit do kosa...nie analytickom poznani...ktore je navyse pri tomto projekte uplne trivialne (mam predsa funkcnu predlohu a vidim, co musim vracat)

4. Mas presne definovane, co je na vstupe commandov

a dalsi mimo, vid. bod predtym, toto argumentujes v prospech reusenutia nejakej casti kodu?

5. Ked budes mat views a transaction script, refactoring controllerov je tiez trivialny

Zase mimo...pomohol si si slovom refactoring....ale je to prepisanie vacsiny kodu v controlleroch...vacsiny

spocitane a zratane....z piatich argumentov ktorymi si sa snazil spochybnit moje tvrdenie o potrebe hodit 80% do kosa pri navrate ku "klasickejsej" architekture....su 4ks uplne mimo a aspon jeden trosku k veci. Super.

"Okrem toho, ziadal som ta iba o jeden controller"....

na toto som uz reagoval...to tejto predstavy o CQRS ambiciu prispievat nemam....(a neviem, ako by som prispel jednym kontrollerom bez fixnutia okolitej architektury)...nerozumiem, nechapem...co a preco odomna chces....

"pretoze sa mi neche pisat RAW sql commandy, nechcem zatial byt zavysli na kontretnej DB, lahko sa to deployuje, lahko sa to mockuje v testoch a vie to bezat inmemory aj bez DB enginu."

OK, tazke nic, co by Ti chybalo pri NoSQL databaze....

a mocky v integracnych testoch? Pre mna silna kava a uplne ina tema.

"ak nemas v umysle urobit nejaky contribution, ani sa neunuvaj odpispovanim"

napisal som Ti dovody, preco nemam zaujem/motivaciu prispiet...specialne v tom stave v ako je to teraz.

sorry, ale zatial to bezi na starom engine....ktory nie je dobry...ale ak ho ma nahradit nieco, co niekto urobil ako svoj v monych smeroch nevydareny experiment a ku akejkolvek (vecnej) kritike sa stavia takto....tak som zvedavy...ako to bude vyzerat...ked bude vladnut repository, z ktoreho tento portal pobezi...(= zacinam mat pochybnosti, ci som urobil dobre, ze som sa to snazil podporit)

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
18.9.2018 10:23:28
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

take ake argumenty som preskocil?

Ze preco relacna databaza? Ok, takze:

1. SQL + Entity framework tam uz je kvoli asp net identity providerovi a UI. Hladal som aj NoSQL alternativy, ale tam je kvalita a support neporovnatelna s default identity frameworkom a prekodovat to je zdlhava a uplne zbytocna robota.

2. Na command casti mam SQL, ale vyuzivam ju defacto ako dokumentovu databazu (JSON column). Mohol som tam dat NoSQL, ale neprinieslo by mi to absolutne nic, okrem toho, je to trivialne vymenit v buducnosti ak bude treba. Sam si v minulosti viackrat viacerym ludom otrepaval o hlavu, ze aj SQL sa da pouzit ako dokumentova databaza.

3. S query castou je to podobne. Je tam sice relacna databaza, ale je denormalizovana, navrhnuta presne podla poziadaviek views. (Vid napr ForumThread.ParticipantsCsv stlpec, kde si ukladam poslednych n prispievatelov). Co ti vlastne vadi? ze mam relaciu medzi Content tabulkou a tagmi? Ano, dalo by sa tu pouzit NoSQL, ale vzhladom na to ze tu uz mam SQL koli Identity providerovi, neviem co by som tym ziskal. Query cast mi perfektne sluzi tak ako je, mozem si ju ohybat tak ako chcem a vykon je dostatocny.

4. V case ked som to zacal pisat neexistoval .NET Standard 2.0 a NoSQL databazy vacsinou nemali .net core API. Na raw komunikaciu cez REST api som naozaj nemal chut.

5. Nemam skusenosti s NoSQL databazami, takze by som si ani nevedel vybrat

6. Nemal som cas experimentovat s NoSQL databazami. Do EF prave dorabaju providera pre CosmosDB, cakal som aj nato. (EF Core nieje iba ORM, to je iba volitelna sucast -Microsoft.EntityFrameworkCore.Relational)

7. Stale mam v plane to v buducnosti premigrovat, ale teraz by som tym iba zbytocne stracal cas.

8. Vidim sample projekty Dina Esposita (autor Microsoft .NET - Architecting Applications for the Enterprise) ako pouziva SQL databazu v query casti. Napr: https://github.com/despos/NextGen

Co som este preskocil?

[Reakcia]

photo
Liero
18.9.2018 10:39:30
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

V skratke, cisto NoSQL riesenie by bolo pre mna prilis komplikovane a mat kombinaciu viacerych databaz tiez nechem, pokial netreba, no vdaka CQRS to nieje az taky problem urobit ak bude treba

[Reakcia]

photo
T
18.9.2018 16:31:26
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

1. napisat si identity providera pre .net core nie je nic zdlhave ani zlozite, ale ok. Toto je argument. (len pre istotu, uz sme sa posunuli do roviny, ze ked si sa uz rozhodol pre ES, preco si zostal pri relacnej...pri uchovavani udajov releacne je jasne, ze by si robno pouzil tiez). A ono este taka vec, nikde nie je napisane, ked si sa uz rozhodol pre CQRS a ES, ze cele riesenie musi byt. Praveze je rozumne aplikovat len pre tie domeny riesenia, kde ma zmysel a je uplne bezne, ze sa komninuju pristupy pre rozne domeny aj technologie.

2. ano otrepaval a ano da sa, ak nemam lepsiu moznost a ak mam fakt dovod. ..."ale neprinieslo by mi to absolutne nic"....NoSQL by v tomto projekte neprinieslo nic v tom istom zmysel ako nepriniesol nic ES. Ak ale akceptujem, ze som pouzil event sourcing...no sql databaza urcite ma co ponuknut specialne taka, ktora je na ES sita....napr. event store (https://eventstore.org/docs/getting-started/?tabs=tabid-1%2Ctabid-dotnet-client%2Ctabid-dotnet-client-connect%2Ctabid-4(opakujem sa, ma v sebe vsetko potrebne...storage, bus, denormalizery, cep/sagy....)...a teraz spat k bodu 1....identity provider sa Ti zda zbytocne implementovat (OK) alebo celu tuto infrasturkturu implemenetovat a spajat rozne technologie nie?

Trosku ina technika/architektura pri ravendb, ktora zabezpeci to iste....https://ravendb.net/articles/cqrs-and-event-sourcing-made-easy-with-ravendb...zda sa Ti jedno alebo druhe zlozite?

3. Ako moze byt denormalizovana ked tam mas relacie? Povedzme, ze je ciastocne denormalizovana, ale fakt neviem, podla akeho pravidla. Ten paradox je taky, ze kym v command casti to ukladas denormalizovane uplne a cez ES, tu si to spatne ciastocne normalizujes. Btw. JSON sa da idexovat, preco si to neukladal ako JSON ak si potreboval hierarchiu? 

Jedine co ma napada, preco si to robil takto je nejaky linq provider a uvahy o jeho pouziti....aj ked si neviem predstavit, preco by si potreboval relacie...

4. OK, toto neviem posudit, uz sa neviem preniest spat v case, aka bola situacia, ale verim, ze nebola najlepsia. (napr. mongo provider bol urcite pred 1.5 rokom)

5. OK, to beriem, ale v podstate nech by si si vybral ktorukolvek dokumentovu, neurobil by si zle.(aj nedokumentovu, ale tam je zvacsa zlozitejsi start)...

6. OK, ale cakat na cokolvek od MS sa nevyplaca (nie v zlom, ale par sklamani)....

7. Len to je dvojsecne...ked to budes posuvat dalej narastie komplexnost a zacnes byt zavisly na specifickych features, ktore pri no sql mat nebudes (mozno)....

8. Teraz neviem, k comu sa mam vyjadrit...aj ja pouzivam pri CQRS (v niektorych pripadoch (dokonca vo vacsine) relacnu db aj na Q cast. Ale keby som sa z nejakeho dovodu rozhodol davat do MS SQL udaje aj pri ES....urcite by moj query model nebol relacny...z liniek sa neviem vysomarit...meno som uz pocul, ale nepoznam tvorbu/nazory....skus mi poslat nejaky normalny link, nech vidim co robi a na co sa odvolavas...

9. Podla mna si sa pustil aj tak do komplikacie, ktoru si uz mohol dotiahnut, to no sql by podla mna odobralo par problemov na konci dna.

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
19.9.2018 9:55:23
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

1. "nikde nie je napisane, ked si sa uz rozhodol pre CQRS a ES, ze cele riesenie musi byt. Praveze je rozumne aplikovat len pre tie domeny riesenia, kde ma zmysel".
Zeby ma to uz napadlo? Ved tam mam Osobitny DbContext pre veci nesuvisiace s contentom. No napriek tomu som sa minimalne v tejto faze chcel vyhnut polygot storage, hoci by to architektura elegantne umoznila.


3. "Povedzme, ze je ciastocne denormalizovana, ale fakt neviem, podla akeho pravidla."
a) Jednoducho query model som si prisposobil tomu, aby sa mi to lahko a efektivne queryovalo. To je jeho prvorada uloha, nie? Kde je napisane ze vsetko musi byt uplne denormalizovane?

"Btw. JSON sa da idexovat, preco si to neukladal ako JSON ak si potreboval hierarchiu?"
b) Nerozumiem, preco by som mal znasilnovat SQL databazu, ked mozem jednoducho vyuzit to co mi ponuka. Unika mi nieco?

c) Hovorime napriklad o relacii ForumThread -> ForumPosts? No jednoducho v Index viewe nacitam ForumThread bez postov a v Detail viewe aj s postami. Okrem toho, ak bude v v jednom threade vela postov, bude treba spravit strankovanie. Ako by som to robil s JSON column?

d) Ano mohol by som si spravit separatne denormalizovane view pre Index a pre Detail, ale momentalne nevidim na to dovod. Ak ho uvidim, nieje to problem dorobit.
*Ja totiz vzdy zacnem tym jednoduchsim riesenim pokial sa to da lahko v pripade potreby zmenit. To je zakladny princip agilneho vyvoja, nie?

e) "Ten paradox je taky, ze kym v command casti to ukladas denormalizovane uplne a cez ES, tu si to spatne ciastocne normalizujes."
Nerozumiem. Do command casti mi nikdy neprudili normalizovane data, takze som ich ani nedernomalizoval a tym padom nemozem ani "spatne" normalizovat. Okrem toho, neviem ci ta relacia sa da nazvat normalizovanie dat. Ked tam vyhodim FK, tak uz budu denormalizovane? Ja ich jednoducho davam do formy zmysluplnej pre query model pri zachovani nejakej pragmatickosti.

[Reakcia]

photo
Liero
19.9.2018 10:13:02
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

8. "meno som uz pocul, ale nepoznam tvorbu/nazory....skus mi poslat nejaky normalny link, nech vidim co robi a na co sa odvolavas..."
Ako sorry, ale spytaj sa Cortany, nebudem ti robit assistentku :)

[Reakcia]

photo
T
19.9.2018 23:45:02
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

1. "Ved tam mam..."

ok, super beriem, ale o to cudnejsie sa mi zda, ze si argumentoval existujucim identity providerom pre ms sql ako niecim zasadnym...

3a) "aby sa mi to lahko a efektivne queryovalo"

Podla mna len "lahko" (v tom zmysle, ze mas linq, to asi chapem)...efektivne nie...vid. nizsie.

"To je jeho prvorada uloha, nie? Kde je napisane ze vsetko musi byt uplne denormalizovane?"

V podstate je to tak ako pises..doraz musi byt ale mal byt aj na tom, aby boli udaje predpripravene v max moznej miere pre zobrazenie, Q vrstva tenka a jednoducha. idealne len to zobrat a zobrazit. Ze ma byt Q denormalizovana napisane nikde nieje, len taku separaciu ako si urobil robis s nejakym zamerom, ale ked povies, ze chces dynamicke queries, joiny a potrebujes relacie, tak tan zamer, pri ktorom ma zmysel popieras...proste nevidim UC kedy by sa toto oplatilo...a som spat pritom, ze si stratril viac ako si ziskal oproti klasickemu relacnemu modelu

3b) "Nerozumiem, preco by som mal znasilnovat SQL databazu"

ale ved Ty si to urobil niekolko krat...znasilnil...a dost brutalne....a tam kde si mal ziskat profit z toho znasilnenia, tam si ho zahodil...priklad....

Napr. Ty potrebujes tranzakciu v Q casti, kedze "view" mas vo viacerych tabulkach a asi nechces, aby sa Ti do jednej ulozilo a do inej nie (bud sa to cele ulozi, alebo nie) a uz Ti ide cely profit z takejto fyzickej separacie C a Q do cudu...narastli Ti zapisy, ale nezbavil si sa tranzakcii, lockov, blokovania readov (trosku sa tomu da este pomoct)...tranzakcii si sa zbavil v C casti, kde to je menej kricke(menej zapisov ako citani), ale vniesol si ich do Q, kde to hrame na maximalizaciu efektivitu...

3c) neviem, ako mam odpoved na otazku...ci mam akceptovat...ze tu mas MS SQL a musis ES ako najlepsie vyriesis tento problem....ok, skusim odpovedat po svojom...

zadanie...thread/post/strankovanie

zabudnime na zaciatok na to, ze je toto mini projekt a povedzme, ze mame desattisice paralelnych requestov za sekundu, ako by mohol vyzerat query model....

mnozina rieseni je velka, zalezi od architektury pouzitej NoSQL databazy, aka je napr. efektivna pri praci s nested collections, ale jedno z moznych rieseni...skusim jedno z univerzalnych rieseni nad hypotetickou a velmi hlupou no sql databazou....

Riesenie:

a) Collection "Forums"(inak preco to nie je Thread?) 

key (idForum) aka nieco ako clustered index v MS SQL, podla klucu su zaznamy zoradene a mozno je nim dokonca riadena fyzicka adresacia

document { Title, Owner, IdForum }

b) Collection "ForumPosts"

key (idForum, page) aka nieco ako clustered index v MS SQL

dokument { ForumTitle: '..', Owner: '...', IdForum: 123, Page: 1, Posts: [ {Text:'prvy'}, {'Text:druhy'} ] }

offtopic: na toto pri casti no sql databaz netreba denormalizer...uplne staci incrementalny map reduce....(ravendb,couchdb)...

OK a teraz MS SQL (ze musim toto nejako vybojovat s MS SQL a zaroven maximalizovat vyuzitie jeho moznosti) 

v MS SQL by si mohol urobit napr. tabulku...kde page, idForum budu stlpce, ktore tvoria kompozitny index/clustered key...a treti bude dokument v json...v tomto momente pri Enterprise MS SQL mas otvorene dvere tuto tabulku jednoducho skalovat s vyuzitim pokrocilich technik v enterprise verzii (partitioning a clustering)...pri navrhu budes asi este brat do uvahy fakt, ze najnovsie stranky su hitovane castejsie ako starsie. (samozrejme, aj tento pristup ma nejake nevyhody, urcite na to prides, su ale riesitelne). 

na gui zoberies JSON a deserializujes na objekt a zobrazis(templating). Nepotrebujes nic z ORM/EF infrastruktury ani len mapper. Mas ultratenku Q vrstvu ci ms sql alebo no sql.

 3e) vid priklad vyssie, jeden aspekt toho paradoxu, snad to je takto jasnejsie...(to nie je pragmatickost, to je malo fantazie - sorry, nenapadlo ma lepsie slovko, fakt nechcem dehonestovat...proste si zvyknuty na EF, si zvyknuty na komfort mapovania, model first, linq etc. to je dovod, preco sa Ti to podla mna zda ok...ale sorry, este raz, snad uz bude jasne, co sa snazim od zaciatku povedat...(fakt to nemyslim zakerne alebo nieco podobne...)

a) z hladiska CQRS arch si nic nenacvicil, je to taky zly prototyp, kde si si nenacvicil zaklad pre tu velku skalovatelnu architekturu, ktoru by si mozno raz aplikoval a je to pochopitelne, nemal si realny driver, robil si kompromisy, ale v konecnom dosledku si nedosiahol viac, ako s relacnym modelom.

Ak by si isiel pragmatickym stylom...mozno skoncis pri uplne jednoduchej separacii...ako som ti odporucal ja...ze povazujem za maximalne zmysluplnu....C - klasicka relacna db, jeden context Q - view, materialized view, a druhy EF context s konfiguraciou pre efektivne queryovanie (NoLock, vypnutie cache etc.) 

b) nikto sa na tomto nic nenauci z komunity, nemozes (dufam) to pouzit ako referencu CQRS/ES architekturu, komunite sa bude tazsie prispievat, mozno to niekoho odradi...

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
T
19.9.2018 23:48:29
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

8. sorry, ale ta linka nefunguje....chcel som len priklad, kde uvidim konkretne, na co sa odvolavas...fakt nemam cas googlit na zaklade nejakych naznakov...."ako pouziva SQL databazu v query casti"...kde to mam vidiet?

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
20.9.2018 11:01:07
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

3b) "Ty potrebujes tranzakciu v Q casti, kedze "view" mas vo viacerych tabulkach...a uz Ti ide cely profit z takejto fyzickej separacie C a Q do cudu"

Sorry, ale nesuhlasim. Z hladiska performance minimalne to, ze mam materializovany view, ale to v tomto projekte nieje podstatne a preto som QueryModel modeloval tak ako som modeloval, hoci netvrdim ze to je najlepsie a konecne riesenie. 
Ja vidim benefity inde ako v performance.
Napriklad na navrhnutie dobreho relacneho modelu musis brat ohlad aj na to, ako z toho budes tahat data a teda musis mat pomerne dobru predstavu ako bude portal vyzerat. Alebo dbat nato, ako si zvolit agregaty, co tiez vyzaduje dobru analyzu predtym ako zacnes kodit.
Ja som tu predstavu napriklad nemal, ale Command Model som si vedel vytvorit aj tak a agregaty si viem teraz lubovolne menit. Celu command cast som mal hotovu skor ako som mal vystup od UX designera. Potom som nakodil HTML, potom CSHTML s fake ViewModelmi, potom som urobil querymodel, tak aby sa mi lahko naplnali viewmodely a potom denormalizeri. Takyto postup je pre mna mimoriadne pohodlny a lakavy a to hlavne v timoch kde su FE a BE developeri.
Dalej napriklad nemusim pisat defacto denormalizery v transaction scripte v command casti, tak ako si to ty navrhoval (LatestActivity, Notifications etc), ale v Query casti, teda tam kam to patri. Atd, je toho viac, uz som spominal

3c)

btw, vola sa to ForumThreads, neviem odkial si zobral Forums....

NoSQL riesenie - Ok, takze pri premenovani ForumThread.Title musis updatovat napriec dvoma kolekciami, takze mas defacto ten isty problem s konzistenciou, ako keby som vypol tranzakcie v mojom SQL denormalizeri. Uslo mi nieco?

SQL riesenie - ak som spravne pochopil, tak si v tabulke ForumPosts len prehodil stlpce to JSON stlpca a zgrupil ich podla PageNumber. Ako zobrazim v Detail viewe ForumThread.Title ForumThread.Content a ForumThread.Tags? Ak ich pridam do toho JSON, tak mam zasa ten isty problem, ze musim updatovat dve tabulky, navyse to nemozem robit jednoduchym UPDATE commandom. Zasa som tam kde som bol, ked vypnem tranzakcie. v mojom denormalizeri (chapes, preco nechapem tvoju poznamku o tranzakciach?)

Nuz teda okrem mozneho zlepsenia performance tu nevidim vyhody. Pridem o skvele queryovacie moznosti, ktore mi SQL ponuka. Hned prve co ma napadne je PageSize tam mam ako volitelny parameter, takze takto to aj tak nepojde spravit. Nehovoriac o tom, ze sa tam neda aplikovat ziadny filter atd.. Nieje lepsie vyuzit SQL ako hrat sa na NoSQL? Vobec nerozumiem tomuto tvojmu zmyslaniu, ved to je postavene na hlavu. 

Ty stale vychadzas z toho, ze CQRS ma zmysel iba ked chces skalovat a maximalizovat performance a podla toho mi ponukas riesenia, ale ja som z tohto predpokladu vobec nevychadzal (a nevychadza z neho ani Greg Young, ani Dino Esposito a dalsi...).

Je tu este jedna vec. Pre Fulltext a pre MostViewedTags a pre MostActiveUsers nemam vlastne denormalizeri. Zatial. QueryModel som si pragmaticky navrhol tak aby som tieto data vedel lahko ziskat (Optimalizovany pre queries). Kedze mam SQL databazu, mohol som si to dovolit.  Som si vedomy dosledkov, pre mna je dolezite, ze momentalne mi to takto vyhovuje a je to jednoduche prerobit.

 

[Reakcia]

photo
T
21.9.2018 19:10:28
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

" Z hladiska performance minimalne to, ze mam materializovany view"

teraz Ti uz nerozumiem, ja som spominal materializovane views ako techniiku, ktoru mozes pouzit nad relacnym modelom. Je to urcita forma denormalizeru. Ak ju pouzijes Ty, tak ku svojim tabulkam v Q casti a denormalizerom, pridavas dalsiu vrstvu denormalizerov(dalsie zapisy, dalsia komplexita). Toto nedava zmysel, alebo nechapem, co si chcel povedat tym materializovanym view. Inak...naco mi je denormalizer, ktoreho vystup treba este denormalizovat pouzitim standatdnych dernomalizacnych nastrojov relacnej databazy?

"Napriklad na navrhnutie dobreho relacneho modelu musis brat ohlad aj na to, ako z toho budes tahat data a teda musis mat pomerne dobru predstavu ako bude portal vyzerat. Alebo dbat nato, ako si zvolit agregaty, co tiez vyzaduje dobru analyzu predtym ako zacnes kodit."

ok, co porovnavame. Navrh domenoveho modelu

a) s relacnou dabatazou s povedzme nejakou jednoduchou formou cqrs

vs

b) navrh domenoveho modelu s ES?

V oboch pripadach je zaklad ten isty...entuty/aggregaty domenoveho modelu si musis namodelovat a behavior niekde popisat (ty mas jednoduchu domenu, ktoru mas celu v hlave, takze toto rovno robis v kode ale na trochu vacsom projekte toto uz nefunguje alebo funguje zle)

pri ES naviac musis modelovat domenove eventy, zaoberat sa naozaj rigidne aggregatmi, v Q casti modelovat denormalizery vo vazbe na domain eventy....a aggregaty, to je zrovna to, co pri relacnej db(na urovni relacnej db) riesit velmi nemusis resp. nemas ako, jedine obchadzanim relacneho modelu.. 

Jednoducho CQRS s ES prinasa komplexitu(o tom pekne hovori fowler), za ktoru ma zmysel zaplatit len vtedy, ak je na to dovod ..napr. poziadavky na performance....alebo nejake prisne poziadavky na auditovatelnost (ale ani to neznemana, ze Ti len nestaci logovat udalosti...)

"Celu command cast som mal hotovu skor ako som mal vystup od UX designera"

To iste plati ale aj pri old school designe so "servismi"/transaction scriptonm. Nerozumiem.

"Takyto postup je pre mna mimoriadne pohodlny a lakavy a to hlavne v timoch kde su FE a BE developeri."

Detto pri serviceoch...mam pocit, akoby si prvykrat objavil separaciu medzi FE a BE a mas pocit, ze to jedinecna vlastnost  Cqrs...btw. v tvojom pripade to ale oddelene nie je....keby si mal urobene commandy, command handlery a domain model...potom by to platilo...(co je samozrejme pri takomto projekte vrazda a ja preto je lepsie siahnut po jednoduchsej architekture, pri ktorej tu separaciu dosiahnes pri ovela mensej komplexite)

"v command casti, tak ako si to ty navrhoval (LatestActivity, Notifications etc), "

ok, toto je typicky CEP scenar, ktory krasne zapada do ES architektury ale zase riesitelny aj klasickym pristupom(ci uz na strane C ako si napisal, ale aj na strane Q cez view,index...a pod.), a je to taka marginalita, bez kritickych poziadaviek na perf.. ze sa len na zaklade nej rozhodovat nemozes (toto je prvy agument z posledneho prispevku, ktory mi dava zmysel)

"vola sa to ForumThreads, neviem odkial si zobral Forums...."

popravde neviem, zvacsa pisem pomedzi ine domace aktivity...ok, sorry

"akze mas defacto ten isty problem s konzistenciou"

uslo....otazka znie s akou konzistenciou...v mojom pripade je odpoved, ze mam problem s eventualnou kozistenciou, nie s konzistenciou z hladiska ulozenia noveho riadku do view a koznistenciou na urovni jedneho zaznamu...blokovanim......zvacsa chcem zarucit (nie vzdy), ze sprava bude denormalizerom resp. vsetkymi spracovana, to mi riesi msgbus nie storage....a ked sa dotazujem, beriem veci z jedneho "adresneho miesta"...nerobim join...

SQL riesenie si pochpil spravne "len" som urobil clustered index podla toho, ako k zaznamom budem pristupovat, len som ulozil udaje pre zobrazenie tak, aby som ich nemusel skladat.

"Ako zobrazim v Detail viewe ForumThread.Title ForumThread.Content a ForumThread.Tags? "

Takto....(ak spravne rozumiem otazke)

{ ForumThreadTitle: '..', ForumThreadContent: '...', ForumThreadTags:['t1','t2','t3'], Page: 1, Posts: [ {Text:'prvy'}, {'Text:druhy'} ] }

(upozornujem, ze je to len jedno z rieseni a to sprave je zavisle od konkretnych vychodisk - o tom je big data aj cqrs....napr. pomer medzi readmi a frekvenciou aktualizacie atributov...btw. ja osobne by som zakazal moznost zmeny title, ak tam je viac ako jeden prispevok...ked raz prispiem do threadu s nazvom..."O cervenej ciapocke"....nemoze ho niekto premenovat uprostred diskusie na "O troch prasiatkach"....

Ak ich pridam do toho JSON, tak mam zasa ten isty problem"

vitaj vo svete denormalizacie...

"navyse to nemozem robit jednoduchym UPDATE commandom."

mozes...JSON_MODIFY od MS SQL 2016...(ale toto je dobry postreh, presne na toto SQL databaza stavana nebola, aj ked ma podporu pre JSON...a druha vec, ak su taketo updates caste, potom je na mieste prehodnotit Q model...a prejst na scenar...ze info o fore jeden view a druhy strankovane prispevky a zobrazenie bude vyuzivat oba)...

"Zasa som tam kde som bol, ked vypnem tranzakcie"

pri update ano ale aj tak a) je to radovo menej lockov, neriesis konzitenciu cez viac tabuliek, ale len atomicky v jednej... b) ak je update tak casty oproti vyhodam toho modelu, tak ho prispobis, vid vyssie

"Nuz teda okrem mozneho zlepsenia performance tu nevidim vyhody"

spravne ani ja(je to cele o perfomance a skalovatelnosti)...keby si tie uvahy dotiahol do konca, tak si odpovedal na to, preco sa pri takomto projekte oplatilo zostat pri klasickom relacnom modely...a max riesit Q model cez viewy....

"Pridem o skvele queryovacie moznosti, ktore mi SQL ponuka. "

opat spravne, ak ocakavas moznost dynamickeho queryovania, tak no sql nie je zvacsa odpoved...aj ked v tomto pripade so znasilnenym MS SQL problem nevidim...ak chces queryovat....tak si urobis taky view, aby si vedel....

a ze sa moze menit page size? Ano...tak si urobis denormalizaciu pre kazdu velkost stranky (15,20,25)....(ale to si zase vniesol specifikum, na ktore treba reagovat volbou modelu/pristupu)....ak chces a mozes si dovolit flexibilutu a chces mat otvorene dvere pre kazdu pomyslenu query a mozes si to dovolit...ostan pri relacnom modely a neries denormalizaciu...este inak, takuto denormalizaciu riesis vtedy, ked si nemozes dovolit to riesit inak(perf. poziadavky, objem dat)...

"Nieje lepsie vyuzit SQL ako hrat sa na NoSQL?"

a nie je cele toto o tom, ze som Ti snazil ukazat, ze v tomto priapde je lepsie zostat pri relacnom modely (ked uz navyse MS SQL je zakladnou volbou)....nenapisal som skor ako som sa pustil do uvah o znasilnovani MS SQL...ze beriem ako predpoklad...("ze musim toto nejako vybojovat s MS SQL" a nemozem pouzit nieco vhodnejsie?) Nemozes nechat SQL na chodniku napoly znasileny a citit sa moralne nadradenym voci tomu, co to dotiahol do konca. Navyse, ked si toho druheho na to naviedol :-)

"Ty stale vychadzas z toho, ze CQRS ma zmysel iba ked chces skalovat a maximalizovat performance "

CQRS? Zasadny OMYL, opak je pravdou...vrat sa k tej casti, kde som Ti pisal definiciu CQRS a kde si mi vycital, ze to co navrhujem nad relacnym modelom(Q ako Viewy) nie je CQRS. (nechce sa mi to hladat, aby som presne citoval)

a ano... Architektura s ES, MsgBus, Denormalizeri etc. ano, tam sa to robi pre perfomance/skalovatelnost, nic ine ma nenapada, kedy to ma zmysel...ok, este pri typickych CEP domenach, kde nad tym chces postavit nejaky event stream processing.(ale stale to neznamena, ze Ti nestacia len domain eventy)

 "a nevychadza z neho ani Greg Young, ani Dino Esposito a dalsi."

a ani ja, hore mas dokaz, ze aj u mna to tak nie je...zostava mi verit, ze si to vtedy len prehliadol...

"pre mna je dolezite, ze momentalne mi to takto vyhovuje "

ved ok, toto je tak maly projekt, ze nemas sancu urcit sa na vlastnych chybas pri volbe zleho designu...ale ak skusenost z tohoto zovseobecnis pri velkom projekte v zmysle...ze heureka objavil som univerzalnu a najlepsiu architekturu, ktoru teraz idem pouzit vsade...tak mozes mat problem (verim, ze to tak nebude)...cize..."nic" sa na tomto nenaucis, vniesol si tam komplexitu (ktoru este nevidis a hlavne ju nevidis ocami niekoho ineho)...

viac Ti mozno dalo do buducnosti aplikovania CQRS, ES, NoSQL (pri vsetkej skormnosti) moje kostrbate rypanie...ako to, co si nakodoval...(ale keby nebolo do coho rypat, tak nie je ani toto...takze beriem spat...zmysel to malo...dufam)

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
22.9.2018 16:25:25
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@T: inak vdaka za trpezlivost, je obdivuhodna :) myslim ze sa konecne niekam dostavame.

"preformance...materializovane views...myslim ze ti nerozumiem"
Zle som sa vyjadril. Nemyslel som Indexed Views v MS SQL alebo Materialized Views v Oracle, ale to, ze ukladam data v takej forme, v akej ich zobrazujem. Napriklad ForumThread ma v sebe poslednych 5 participantov, co by som z klasickeho relacneho modelu komplikovane vytahovat.

"pri ES naviac musis modelovat domenove eventy, zaoberat sa naozaj rigidne aggregatmi"
 praveze sa nemusim zaoberat agregatmi. Vsimni si ze v eventoch nikde nemam AggregateId.
Praveze ja si teraz mozem lubovolne zvolit AggregateRoot a napisat k nemu jedoducho Repository. Dokonca mozem velmi jedoducho mat jeden Event vo viacerych agregatoch. A co je dolezitejsie, mozem si zmenit AggregatRoot bez toho aby som menil Eventy, alebo Commandy, alebo databazu (max treba preindexovat)
Cize dajme tomu ze zacnem EventStormingom, z toho mi vypadnu eventy, commandy a potom z toho uz tie Agregaty akosi prirodzene vyplynu. A ked sa pomylim, nieje problem ich zmenit.
Priklad 1:
V nasom pripade som sa nevedel rozhodnut, ci Aggregat ma byt ForumThread, alebo ForumPost, kedze ForumPost moze mat neskor Votes, pripadne Comments a ktovie co este. Teraz tento problem nemam a mozem dobre spavat.
Priklad 2:
Na mojom poslednom projekte architekt architektov (v asi najvacsej technologickej korporacii na svete) zvolil agregaty v business domene, ktoru sam vlastnil a vymyslel. A zvolil ich dobre (naozaj je skuseny makac). Az kym sme nezacali migrovat data zo stareho systemu a nastali take nepredvidatelne skutocnosti, ze sme dospeli k tomu, ze neboli zvolene dobre. Refactoring uz neprichadzal do uvahy, vyzadovalo by si to privela zmien v relacnej databaze aj v kode.
Nehovoriac o tom, ze ten system bol defacto ES v zmysle ze sme iba pridavali data a nikdy nemenili, kvoli tomu ze sme potrebovali historiu. Keby sme to robili ako ES/CQRS, nebol by ziaden problem, no takto som musel implementovat velmi skarede workaroundy.
 
 
"a nie je cele toto o tom, ze som Ti snazil ukazat, ze v tomto priapde je lepsie zostat pri relacnom modely" - no ved ok, toto som nikdy nespochybnoval. Lenze teraz boli ine temy:
  • Pouzit pre Q NoSQL? Tu si ma nepresvedcil, naopak utvrdil, ze som spravit dobre v tomto konkretnom pripade.
  • Ked uz SQL, tak uplne inak. Tu si ma uz duplom nepresvedcil, to tvoje riesenie by bolo takmer katastrofou pre tento projekt :)

"a ano... Architektura s ES, MsgBus, Denormalizeri etc. ano, tam sa to robi pre perfomance/skalovatelnost, nic ine ma nenapada, kedy to ma zmysel"

uf, uf, tak toto je silna kava, na toto musime zalozit osobitny thread, ale zober si taky GIT, co vsetko umoznuje - historia, porovnavanie verzii, moznost navratu k verzii, docasne vie fungovat offline, resp eventuelna synchronizacia so serverom, geograficky distibuovane systemy kde treba riesit konflikty...

[Reakcia]

photo
T
22.9.2018 23:02:47
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

uz chapem, ze vysledkom toho, co robia Tvoje denormalizery je meterializovany view ako v oracle...a ja len poznamenal, ze hovorim od zaciatku, ze by Ti uplne stacili materializovane view/indexed views aj v MS SQL (aj ked tie maju viac obmedzeni ako napr. v ora)....a hovorim aj to, ze si ciastocne normalizujes, cim popieras zmysel vlastnych denormalizerov...poslednych 5 participanov je malina aj pri relacnom modely, toto zrovna nie je kriticky UC a nie pri takomto pocte zaznamov.

"praveze sa nemusim zaoberat agregatmi."

Celemu odseku nerozumiem. Ked navrhujem strukturalny model, musim sa rozhodnut(navrhnut) co je aggregat. Eventy by mali byt vzdy viazane a uchovavane po aggregatoch. Ak replayujem, replayujem eventy pre jeden aggregat aby som ziskal jeho stav. Aggregate Id musis mat pri kazdom evente.(mozes to volat ID, ale to ID musi byt aggregat Id).... 

Jeden event vo viacerych aggregatoch? Fakt nerozumiem. Ako? Preco? Daj priklad pls..

Pri relacnom modely ale aggregat Id nepotrebujes a na urovni db modelu nad aggregatmi uvazovat nemusis, lebo normalizujes. Nad tym, co je aggregat uvazujes mozno vyssie na urovni data access. Ak pouzivas EF tak ani tu nie, lebo mas "repository" po entitach, nie aggregatoch. O agregatoch uvazujes (mozno, ak patris k 1% developerov ktory o aggregatroch explicitne uvazuju) tam, kde robis .Orders.GetById(1).Include("OrderLine")

"ma byt ForumThread, alebo ForumPost"

klasicka dilema ano ;-) ale ten priklad fakt nechapem...nechapem celu tuto pasaz, co si chcel povedat...skus mi to napisat inak. Jedine co mozem povedat....ze refactoring aggregatov a eventov je makacka, ale rata sa s tym. Ak to potrebujes robit uz v produkcii....tak navyse musis urobit transformaciu a prehratie vsetkych eventov na eventy novych aggregatov.

Este otazka, napis mi, aj to, ako si zvolil aggregaty a na zaklade coho si sa rozhodoval. (z konstatovania comments a votes mi nie je jasne, ako to dopadlo a co z toho vyplyvnulo pre volbu aggregatov)

K tomu prikladu s kolegom...z mojej skusenosti je to relativne bezne, ze sa na projekte v neskorej faze objavi nieco, co vyvola potrebu refactoring modelu (aj relacneho), co si pri jeho povodnom navrhu nemohol zohladnit...a neda sa tomu zabranit...preto je dobre mat udrziavatelny/otvoreny kod...ale ani to nezarucuje, ze sa to v pokrocilej faze mozes dovolit...a jednoducho to dokoncis s urcitou nedokonalostou....(o niecom podobnom asi pises, ak som pochopil)...

a.d. "presvedcil-nepresvedcil"

no nepresvedcil som Ta hlavne preto, ze
a) nemas perfomance kriticky scenar....cize mohol si zostat bud pri relacnom...alebo akomkolvek hybride...a problem architektury sa neprejavi...

b) navyse aj komplexnost domeny je tak trivialna...ze nevidis co vnesenie ES vyvolalo...ja len hovorim to, ze ked uz si chcel akademicky vniest ES a CQRS...mal si to vyuzit na to, aby si si nacvicil nieco na velky projekt...a dat si fakt ciel..."robim to pre stotisic konkuretnych...."...inak nemas co konfrontovat...neviem ci mi rozumies teraz. (ze ked si uz obetoval to najjednoduchsie, co mohla rozvijat komunita, uz si to aspon mohol naplno vyuzit vo svoj prospech)

"A.d. GIT"

nepochopil som ten zaver s GIT...co si tym chcel povedat...

 

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
T
22.9.2018 23:17:18
Body: 21520
Najaktívnejší č.: 2

RE: Spigi

este jeden pohlad...

urobit dobru architekturu (udrzatelnu, cistu, lahko pochopitelnu ... bla bla) s transaction scriptom nie je jednoduche (pre vacsi projekt) a tiez je tam urcita variabilita v tom, co sa oplati na mensom a co az na vacsom projekte. A ked fungujes s takymto niecim (zabehnutym v teame) a zaroven mas aku taku skusenost s ES a uplne rozvinutym CQRS, tak proste vies aku dan zaplatis ak si ho zvolis. (produktivita, komplexnost, hybridne technologie....ok, je tu event store ktory ma skoro vsetko co potrebujes v jednom...aj ked ten ma tiez svoje limity napr. CEP engine je pomerne limitovany)...musis vediet, ze sa Ti to oplati, musis mat dovod pre takuto architekturu...a jediny, ktory je naozaj jednoznacny je performance...

Ty mas ovela vacsiu sancu vdaka tomu, kde robis (ak si dobre pamatam), ze taky projekt chytis, co je super. Ja taky aktualne napr. vo vyhlade nemam.  

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
vlko
25.9.2018 9:14:10
Body: 37810
Najaktívnejší č.: 1

RE: Spigi

Takze ked uz mate vyriesene skalovanie a architekturu pre vsetkych 300 ludi co tu za mesiac mozno dojde, tak ako sme sa pohli v release novej verzie?

Lebo seriozne, az sa to raz spusti, tak aj tak tam nik nebude nic dorabat, pobezi to tak x rokov, takze spigiho complain o udrziavanosti je uplne zbytocny. Treba sa niekde posunut, ak chceme aby to tu nezakapalo.

[Reakcia]

photo
Liero
25.9.2018 13:06:27
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

Ako hovorim, funkcnost tam na 90% je, nema zmysel to moc dalej kodit bez pristupu k starej verzii, ale zo Spigiho pristupm sa mam no to chut vy....

[Reakcia]

photo
Liero
27.9.2018 10:38:51
Body: 9780
Najaktívnejší č.: 6

RE: Spigi

@T:
"uplne stacili materializovane view/indexed views aj v MS SQL"

no to sotva. V MS SQL su take obmedzenia, ze sa to neda pouzit prakticky nanic. Urcite nevies spravit indexed view typu zoznam threadov s poctom prispevkov a uz vobec nie so zoznamom poslednych n participantov. Tiez nevies spravit query typu "latest record of each group" - napr poslednu verziu kazdeho threadu, jedine ze by si mal flag na to, ktora verzia je posledna.
A ked uz hovorime o kanonoch na vrabce, tak Oracle je minimalne bazuka :)

"Eventy by mali byt vzdy viazane a uchovavane po aggregatoch."
praveze nemusia a je to tak lepsie. Dokaz je v mojom projekte: Moje eventy o agregatoch nic netusia a predsa si mozem agregaty lubovolne zvolit s tym ze ta logika bude iba v Repository. Napr
public class ForumItemPosted : DomainEvent
{
    public Guid ForumThreadId { get; set; }
    public Guid ForumItemId { get; set; }
    public string AuthorUserName { get; set; }
    public string Content { get; set; }
}

public abstract class DomainEvent
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public DateTime TimeStamp { get; set; }
}
Stale si mozem zvolit, ci agregat bude ForumThread, alebo ForumPost

Co sa tyka ukladania v databaze, tak napr CosmosDB indexuje automaticky vsetky fieldy, ale kazdopadne nieje problem akukolvek databazu preindexovat podla toho ako si zvolis agregaty.
"Jeden event vo viacerych aggregatoch?"
No napriklad UserDeleted moze mat cross bounded-context effekt i ked asi by som to riesil inak. Ale napr pri MicroServices architekture moze byt jeden event spracovavany viacerymi servicmi a kazdy v uplne inom kontexte.
Moze sa stat, ze napr nebudem mat ForumThreadId v evente a  a agregat bude ForumThread:
public class ForumItemDeleted : DomainEvent
{
    public Guid ForumItemId { get; set; }
    public string DeletedBy { get; set; }
    public string Reason { get; set; }
}
ale to je trivialny update.

"...ze refactoring aggregatov a eventov je makacka, ale rata sa s tym. Ak to potrebujes robit uz v produkcii....tak navyse musis urobit transformaciu a prehratie vsetkych eventov na eventy novych aggregatov."

No pokial mas Eventy tak ako ja, a sice ze niesu viazane na agregat, tak je len mala sanca, ze budes ich musiet refaktorovat eventy. Pokial eventy kopiruju skutocnost (to co sa naozaj stalo) tak sa takmer nemas kde pomylit.
Na refactoring agregatov nemusis prehravat eventy. Naco?

"napis mi aj to, ako si zvolil aggregaty a na zaklade coho si sa rozhodoval"
Zatial nijako, kedze tam ziadne M este nemam :) Ak si pamatas, na zaciatku som tam mal plnohodnotny domenovy model, ale pochopil som, ze to je blbost, tak som to vyhodil, ale to nemalo s ES nic spolocne. To lakave na tom je, ze teraz si tam nejaky ten agregat viem z uz existujucich eventov lubovolne dorobit, i ked asi pojdem cestou transaction scriptu.

"K tomu prikladu s kolegom..."
Chcel som tym povedat, ze na tom projekte by ES a CQRS velmi velmi zjednodusili cely projekt a pritom vobec neslo o skalovatelnost a vobec nebolo treba NoSQL. Takto sa museli robit v SQL viewoch uplne sialenosti a aj napriek optimalizacii dotazy trvali prilis dlho. A to musim povedat, ze domenova logika bola pomerne jednoducha, vsetko bolo centralizovane a mali sme tak max 5 online uzivatelov.

"nepochopil som ten zaver s GIT" - git je skvely priklad eventsourcingu. Commity su defacto eventy. Ich prehratim dostanes current state. Q je filesystem optimalizovany pre queries. GIT je distributed version control a teda moze byt replikovany na mnohych miestach. Tiez riesi konflikty pri mergovani. a tiez riesi offline scenare. A pritom vobec nejde o performance pri commitovani alebo queries.
Vsetky tieto vlastnosti si vies premietnut s trochou abstrakcie na rozne ine typicke business scenare. Tako ako pri commitovani "sutazia" developeri o nejaky subor, tak mozu v inom scenari sutazit useri o nejaky resource (napr sedadlo pri kupovani listka na koncert). A mozes mat viacerych sellerov, s tym ze sa synchronizuju len obcas. a tym padom treba riesit konflikty. Presne ako v GITe.
Iny priklad - biometricky system pre utecencov v afrike. Mas viacero kempov, kde sa chodia zaregistovat. Lenze tie kempy su samostatne, vacsinou offline a len obcas synchronizovane s centralnou databazou (vid distributed git). A casto sa stavalo, ze jeden clovek sa zaregistroval vo viacerych kempoch a vytvorili sa viacere identity, ktore bolo treba mergnut v centralnej DB - vid analogiu s gitom pri pushovani. Alebo naopak, clovek chybne rozpoznany ako uz zaregistrovany. Bez ES by ho system pravdepodobne ani nepustil dalej, ale ked ty je ES, tak proste ulozim co sa stalo PersonEnrolled a ked narazim na konflikt vytvorim novy event IdentityConflictDetected a potom niekto rucne rozhodne ako to vyriesit IdentityConflictResolved a query model sa updatne podla toho. Zial riesilo sa to relacnym modelom a bolo to extremne komplikovane. Nehovoriac o tom, ze v takychto pripadoch je audit log nevyhnutnostou.
 

[Reakcia]



Najaktívnejší užívatelia
1. 37810 b. photo vlko
2. 21520 b. photo T
3. 15965 b. photo spigi
4. 15450 b. photo Anonymous
5. 11120 b. photo dudok
6. 9780 b. photo Liero
7. 6920 b. photo siro
8. 6245 b. photo slavof
9. 5395 b. photo duracellko
10. 4710 b. photo xxxmatko