Czy przypadkiem komenda które operuje na różnych BC, albo agregatach nie jest błędem który w przypadku przejściu na mikroserwisy spowoduje transakcje rozproszona?
@@andrzejkrzywda_official Myślę że może chodzi o ten moment gdy jedna akcja użytkownika (utwórz produkt) generuje 4 komendy do 3-ch kontekstów. Czy na ES mielibyśmy jedną niebieską karteczkę "utwórz produkt" czy może od razu na ES mielibyśmy rozbicie na "nazwij produkt" "określ cenę", "ustal stawkę VAT" i to tylko przypadek że są zrealizowane naraz na jednym ekranie?
@@jadzie w idealnym świecie jest task oriented UI i wtedy jedna akcja to jedna komenda. Ale że często nie mamy wpływu na UI to taki wzorzec że jedna akcja to wiele komend jest spoko
![bITconf 2022 - [Jakub Pilimon] Domain-Driven Design: Teoria vs Praktyka. Round 1](http://i.ytimg.com/vi/tUaomDg05kw/mqdefault.jpg)
10 lat w 30 minut a film trwa ponad godzinę ;) Takich dwóch jak nas trzech nie ma ani jednego.
Film tyle trwa, bo później jeszcze jest Q&A 😉 Ale faktycznie Andrzej jak się rozpędzi, to ciężko go zatrzymać 😅
Andrzej w kontekście hotwire - miałeś okazję poznać kiedyś Java'owy framework Apache Wicket? To żyje do tej pory i ma się dobrze.
Czy przypadkiem komenda które operuje na różnych BC, albo agregatach nie jest błędem który w przypadku przejściu na mikroserwisy spowoduje transakcje rozproszona?
Dzięki za pytanie!
Generalnie tak, komenda powinna być obsługiwana przez jedno BC.
Był jakiś moment tego wykładu gdzie wybrzmiało inaczej?
@@andrzejkrzywda_official Myślę że może chodzi o ten moment gdy jedna akcja użytkownika (utwórz produkt) generuje 4 komendy do 3-ch kontekstów. Czy na ES mielibyśmy jedną niebieską karteczkę "utwórz produkt" czy może od razu na ES mielibyśmy rozbicie na "nazwij produkt" "określ cenę", "ustal stawkę VAT" i to tylko przypadek że są zrealizowane naraz na jednym ekranie?
@@jadzie w idealnym świecie jest task oriented UI i wtedy jedna akcja to jedna komenda. Ale że często nie mamy wpływu na UI to taki wzorzec że jedna akcja to wiele komend jest spoko
sekciarze