Pułapka 3.5: zmieniamy stawkę w serwisie od stawek podatkowych, pada transport, a serwis od faktur puszcza zdarzenia w świat ze starą wartością stawki (kiedyś wcześniej odpisanej).
Racja Dariusz! Dzięki za tę uwagę - powinna zawrzeć się w talku pod informacją, żeby zawsze uważać na dzielenie się danymi "ulotnymi", analizować częstotliwość ich zmian i wpływ biznesowy takiego przypadku.
@@JakubPilimon 20:00 Ale to rozumiem teraz tak, że chciałbyś żeby do serwisu od fakturowania przychodził event który zawiera stawkę podatku? A co jeśli ten event przychodzi z serwisu zupelnie niezwiązanego z czymś takim podatki? Czy wtedy np serwis ładowania powininen wiedzieć jaki jest podatek na dzień dzisiejszy?
dsadsa dsadsad idea była taka, ze jeśli zarządzamy serwisem od podatków, to można podzielić się informacja nieczęsto zmienna - z całym dobrodziejstwem inwentarza takiej operacji - właśnie podzieliliśmy się jakaś informacją ze światem zewnętrznym ;) są tradeoffy jak przy każdej decyzji architektonicznej - powinienem o tym dłużej poopowiadac ...
@@JakubPilimon nie no czemu - jak zmieniasz emitujesz zdarzenie w podobny sposób więc jak zmieniłeś to znaczy wyemitowałeś i zapisałeś w bazie. jak padł podczas zmieniania to nie zmieniłeś a jak po zmianie to wyemitowałeś - jest jednak ten mały drobny delay między zmianą a update cache i tu trzeba zastosować jakąś retencję czyli po zmianie stawki dopuszczamy jakiś czas zestarymi stawkami albo... uwaga emitujemy zdarzenie blikujące możliwość sprzedaży do zakończenia i potwierdzenia zmiany stawki z timeout. ogólnie wszystko gra ale jest kilka punktów do dogadania z biznesem na poziomie już mega detalu. może jakieś aplikacje do tradingu wpisują się w rozkminę ale na pewno ne 99,999 biznesowych aplikacji
![[Bydgoszcz JUG - meetup #16] Jakub Pilimon i Michal Michaluk - Introduction to DDD based on examples](http://i.ytimg.com/vi/D1vcLp4ZEYc/mqdefault.jpg)
![[Bydgoszcz JUG - meetup #16] Jakub Pilimon i Michal Michaluk – Introduction to DDD based on examples](/img/tr.png)
![[Bydgoszcz JUG - Meetup #42] Jakub Pilimon - Testing - Love, Hate, Love](http://i.ytimg.com/vi/GjKYLmimGeE/mqdefault.jpg)
Pułapka 3.5: zmieniamy stawkę w serwisie od stawek podatkowych, pada transport, a serwis od faktur puszcza zdarzenia w świat ze starą wartością stawki (kiedyś wcześniej odpisanej).
Racja Dariusz! Dzięki za tę uwagę - powinna zawrzeć się w talku pod informacją, żeby zawsze uważać na dzielenie się danymi "ulotnymi", analizować częstotliwość ich zmian i wpływ biznesowy takiego przypadku.
@@JakubPilimon 20:00 Ale to rozumiem teraz tak, że chciałbyś żeby do serwisu od fakturowania przychodził event który zawiera stawkę podatku? A co jeśli ten event przychodzi z serwisu zupelnie niezwiązanego z czymś takim podatki? Czy wtedy np serwis ładowania powininen wiedzieć jaki jest podatek na dzień dzisiejszy?
dsadsa dsadsad idea była taka, ze jeśli zarządzamy serwisem od podatków, to można podzielić się informacja nieczęsto zmienna - z całym dobrodziejstwem inwentarza takiej operacji - właśnie podzieliliśmy się jakaś informacją ze światem zewnętrznym ;) są tradeoffy jak przy każdej decyzji architektonicznej - powinienem o tym dłużej poopowiadac ...
@@JakubPilimon nie no czemu - jak zmieniasz emitujesz zdarzenie w podobny sposób więc jak zmieniłeś to znaczy wyemitowałeś i zapisałeś w bazie. jak padł podczas zmieniania to nie zmieniłeś a jak po zmianie to wyemitowałeś - jest jednak ten mały drobny delay między zmianą a update cache i tu trzeba zastosować jakąś retencję czyli po zmianie stawki dopuszczamy jakiś czas zestarymi stawkami albo... uwaga emitujemy zdarzenie blikujące możliwość sprzedaży do zakończenia i potwierdzenia zmiany stawki z timeout. ogólnie wszystko gra ale jest kilka punktów do dogadania z biznesem na poziomie już mega detalu. może jakieś aplikacje do tradingu wpisują się w rozkminę ale na pewno ne 99,999 biznesowych aplikacji