GoldenLine
Zaloguj się

konto usunięte

Temat: CQRS czyli co....

Jarek Żeliński:
Posialiście u mnie "niepokój", wydawało mi się, że 'rozumiem" te ideę, ale chyba muszę trafić na problem i "odkryć" że to (taka architektura, wzorzec ) pomaga.... hm...

ale ogólnie wyobrażałem to sobie w ten sposób, że mając ów "agregat" i implementacje jego utrwalania, dodaję do tej pary dodatkowy model, który jest inną abstrakcją "tych samych danych"...

Jak to wyglądało by na jakim diagramie ?
Ja uważam, że zadaniem widoku jest określenie sposobu wyświetlanych danych a zadaniem logiki jest wygenerowanie / obliczenie tych danych.

Raport jest nie jest jedynie 'agregatem np. faktur' bo oprócz danych do raportu wchodzi także logika biznesowa przekształcania danych z faktur na dane raportu.Jakub Wojt edytował(a) ten post dnia 02.04.12 o godzinie 08:28
Link do wypowiedziLink
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: CQRS czyli co....

Jakub Wojt:
>
Ja myślę, że takie pytanie trzeba zadań autorowi koncepcji CQRS. Tzn. Jakiego typu dane ma zwracać Query Model i do jakich widoków... Bo oczywiście to też nie zostało wyjaśnione i każdy (krytyk / entuzjasta) to sobie (czy jest tego świadomy czy nie) dopowiada.

Można je zadać autorowi, albo szukać odpowiedzi u najlepszych.

Greg Young, podczas tej prezentacji, odpowiedział na to pytanie: Query Model powinien zwracać DTOs/VOs. W uproszczeniu, bierzesz ekrany, które widzi użytkownik i na podstawie danych, które one reprezentują tworzysz potrzebne DTO.
Young wspomniał o "małym" mankamencie tej metody - tych obiektów z czasem zaczyna się mnożyć i mnożyć... coś za coś*

Zgadzałoby się to z tym co napisał Wojtek, bo to już nieważne z jakich danych te DTO będą pobierane - czy to będzie bezpośrednio ze storage'u gdzie zapisuje model dziedziny, czy może któryś z wymiarów *OLAPa hurtowni, którą stworzyliśmy specjalnie do odczytów, a może czegoś zupełnie innego.

* wg Young'a tworzenie tych DTO zrzuca się na Junior Programmerów i po kłopocie :)Alan Gabriel B. edytował(a) ten post dnia 01.04.12 o godzinie 22:49
Link do wypowiedziLink

konto usunięte

Temat: CQRS czyli co....

Można je zadać autorowi, albo szukać odpowiedzi u najlepszych.

Greg Young, podczas tej prezentacji, odpowiedział na to pytanie: Query Model powinien zwracać DTOs/VOs. W uproszczeniu, bierzesz ekrany, które widzi użytkownik i na podstawie danych, które one reprezentują tworzysz potrzebne DTO.
Young wspomniał o "małym" mankamencie tej metody - tych obiektów z czasem zaczyna się mnożyć i mnożyć... coś za coś*

Nie jestem ani autorem ani 'najlepszy' ale mimo uważam, że to bardzo zły pomysł (tzn. CQRS i to jak rozwiązuje on pewne kwestie):

1. Nie można implementować logiki VIEW (tworzenie klas DTO) w serwisach. Dlaczego ? Ponieważ w ogólnym przypadku nie wiadomo jak będzie wyglądać GUI (np. dostarczamy coś w rodzaju Allegro API). Nie można tworzyć serwisów pod konkretne GUI.

2. Każda zmiana w DB spowoduje lawinę zmian w DTO.

Co w sytuacji kiedy zmieni się schemat 'DB' ? Czy Greg Young CQRS wziął pod uwagę, że każda taka zmiana będzie się wiązać z lawiną zmian w DTO ? Właśnie po to się tworzy warstwy i abstrakcje, żeby zmiany w jednej części systemu nie wymuszały zmian w innej.

3. Kod generujący DTO będzie redundantny. Klasy DTO, jako że są tworzone dla konkretnych widoków, z zasady tworzą żadnych hierarchii. W konsekwencji każda wspólna część kodu generującego będzie musiała być powielana.
* wg Young'a tworzenie tych DTO zrzuca się na Junior Programmerów i po kłopocie :)

W związku z tym, że należy likwidować przyczyny a nie objawy - ja bym doradzał zatrudnienie projektanta który stworzy dobrą obiektową (DTO i Query coś tam są zaprzeczeniem obiektywności) architekturę.

To właściwie wszystko co mam do powiedzenia w temacie z wątku.Jakub Wojt edytował(a) ten post dnia 02.04.12 o godzinie 11:47
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

Jako autor wątku powiem tak:
- skoro nie ja jeden nie rozumiem CQRS to znaczy, że coś z "nią" nie tak,
- model 'hurtowniany" po przemyśleniach nie pasuje mi do CQRS bo to jednak dwa modele danych a nie jeden plus dwie abstrakcje.
- skłaniam się ku tezie Jakuba: coś nie tak tu z "obiektowością"...

nie jest to podsumowanie ale skutek tego, że nie udało mi się opracować sensownego przykładowego projektu, ktoś ma pomysł?
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: CQRS czyli co....

@Jakub,
Wzorzec ten powstał z myślą o poprawieniu wydajności, ale czy istnieje konieczność wdrażania części odpowiedzialnej za pytania i rozkazy na oddzielnych maszynach? Żeby poprawić wydajność wystarczy chociażby podczas wykonywania rozkazów np. na boku w tabeli w tej samej/innej bazie agregować dane dotyczące wykonywanych rozkazów. To z pewnością ułatwi i przyśpieszy zadawanie zapytań w porównaniu do zapytań po tabelach które mapowane są jakoś na encje biznesowe, w których dane powinny być normalizowane, w przeciwieństwie do tych pierwszych. Oczywiście to nie jedyny sposób. W skrócie wzorzec ten stos widoku trywializuje, model widoku to proste DTO, które są krojone pod potrzeby konkretnego widoku lub wystawianego API. Niemniej to że są to proste DTO nie zwalnia to nikogo od zaprojektowania modelu widoku w poprawny sposób i zgodnie ze sztuką, dlaczego nie można korzystać z dziedziczenia i abstrakcji? Dlaczego nie napisać części wspólnej która pod konkretne wymagania będzie rozszerzana, chociażby. Ciekawa jest teza, że nie można tworzyć serwisów pod GUI, czy wzorzec MVP jest dobrym przykładem na to że jednak można. Natomiast to że zmiany w bazie wpływają na zmiany w modelu widoku jest oczywiste, chociażby z tego powodu, że ta struktura jest właśnie stworzona na potrzeby widoku. Powiedziałbym że to widok wymusza pewną strukturę w bazie danych, oczywiście cały czas mówię o tabelach z danymi agregowanymi i redundantnymi.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

spójrzmy na to inaczej (nadal szukam sensu ;))):
- mamy obiektowy model dziedziny
- mamy mapowanie ORM (Object-relational Mapping)
- mamy model relacyjny

Skoro już mamy model relacyjny jako implementację utrwalania oraz jedno "konkretne mapowanie"
z modelu obiektowego na relacyjny czyli "typowo", to czy ma sens tworzenie jednego mapowania ORM optymalizowanego na zapis a drugiego na pobieranie?
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: CQRS czyli co....

Myślę że ma to sens, widok zazwyczaj potrzebuje jakiejś reprezentacji encji biznesowych, pewnej namiastki/agregacji danych, które niesie ze sobą każda z nich. Często także dane na potrzeby widoku są wyciągane z widoków bazodanowych, procedur, funkcji to wymaga oddzielnego mapowania.
Przy okazji zapytam, gdzie umieścilibyście obsługę projekcji lub obsługę sortowania wyników zapytania?
Interesujące podejście do CQRS: klik.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

zaczynam nabierać przekonania, że problem (CQRS jako próba jego rozwiązania) dotyczy przypadków stosowania relacyjnych baz znormalizowanych "pod" modelem dziedziny i ORMów, rezygnacja z tego, to jest umieszczenie całej logiki w oprogramowaniu (obiektowym) i stosowanie prostych wzorców mapowania obiektu na rekord (lub podobnych), rezygnacji z modelu relacyjnego - problem znika... i CQRS nie ma zastosowania...

wskazany "klik" to opisany przeze mnie model z "hurtownią" do czytania
Link do wypowiedziLink
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: CQRS czyli co....

Jarek Żeliński:
[...] to czy ma sens tworzenie jednego mapowania ORM optymalizowanego na zapis a drugiego na pobieranie?

A zastanowiłeś się, czy do Query Modelu w ogóle potrzebujemy ORMa? Osobiście QM widzę jako cieniutkie proxy (w przeciwieństwie do ORMa, który jest rozbuchaną abstrakcją) bezpośrednio do zapytać do storage'a.

Załóżmy, tak jak napisał Adrian, że posiadamy bazy SQLowe, które trzymają zdenormalizowane/zagregowane dane bezpośrednio z encji naszej dziedziny. I teraz wysyłamy żądanie do QM... i co się dzieje? Na QMie wywołujemy bezpośrednie zapytanie/zapytania do bazy SQLowej, które ma Nam zwrócić nie więcej niż oczekiwane przez widok dane.
Nie ma tutaj, żadnej cięższej logiki - tylko ogromne pole do popisu przy skalowaniu, jak chociażby możliwość strojenia zapytań (która to w ORMach.. no cóż, nie istnieje). Nic się nie zmienia też, gdy tą hipotetyczną bazę SQLową zamienimy na dokumentową, obiektową albo w miarę potrzeb grafową - możemy tylko zyskać.

Osobiście zrezygnowałbym nawet ze stricte DTO na rzecz luźniejszych struktur jak np. tablice. Owszem tracimy formalny kontrakt, ale możemy kontrolować jego dotrzymanie w testach.
Link do wypowiedziLink

konto usunięte

Temat: CQRS czyli co....

Wzorzec ten powstał z myślą o poprawieniu wydajności,

Źródła ? ;)
Czy chodzi o wydajność programisty czy o wydajność systemu ?

... trochę głupio optymalizować wydajność systemu korzystając z technologi mającej na celu optymalizację wydajności programistów (obiektowa architektura) .
ale czy istnieje konieczność wdrażania części odpowiedzialnej za pytania i rozkazy na oddzielnych maszynach?

No właśnie, idea bez sensu. Dlaczego dwa oddzielne interfejsy i podział np. 25 maszyn + 1
ma być lepsze od 26 maszyn i jeden interface ?
Żeby poprawić wydajność wystarczy chociażby podczas wykonywania rozkazów np. na boku w tabeli w tej samej/innej bazie agregować dane dotyczące wykonywanych rozkazów. To z pewnością ułatwi i przyśpieszy zadawanie zapytań w porównaniu do zapytań po tabelach które mapowane są jakoś na encje biznesowe, w których dane powinny być normalizowane, w przeciwieństwie do tych pierwszych.
Oczywiście to nie jedyny sposób.

A jakie są inne ?
Ciekawa jest teza, że nie można tworzyć serwisów pod GUI, czy wzorzec MVP jest dobrym przykładem na to że jednak można.

A jakiś projekt ?
Natomiast to że zmiany w bazie wpływają na zmiany w modelu widoku jest oczywiste,

Modelu widoku ...
Widok nie ma modelu bo widok niczego nie modeluje, mkey ? :)
Powiedziałbym że to widok wymusza pewną strukturę w bazie danych, oczywiście cały czas mówię o tabelach z danymi agregowanymi i redundantnymi.

Czy widok wymusza funkcjonalność 'biznesową' ? :)Jakub Wojt edytował(a) ten post dnia 03.04.12 o godzinie 19:16
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

znowu chyba Jakub ma rację:
czy to nie jest tak, że "jeżeli nie myślimy o implementacji utrwalania to nie ma CQRS"?????
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: CQRS czyli co....

@Jarek w czym konkretnie ma rację? W momencie projektowania domeny nie myślisz absolutnie o utrwalaniu, zaczynasz się nad tym zastanawiać gdy chcesz coś zaprezentować użytkownikom.
@Jakub po kolei:
1) Wzorzec poprawia wydajność systemu szczególnie w aspekcie prezentacji danych użytkownikowi.
2) Jaki masz problem z tym podziałem na parę maszyn?
3) Jak Ty rozwiązujesz kwestie prezentowania danych użytkownikowi w swoich aplikacjach, załóżmy że mamy system z Fakturami Jarka, masz repozytorium(FakturaRepozytorium) operujące na grubych encjach (Faktura), logika biznesowa rozsmarowana po elementach modelu domeny. Dostajesz następnie wymaganie: użytkownik ma możliwość wyświetlania faktur, faktury mają być prezentowane po 50 na stronie z możliwością nawigacji pomiędzy stronami(paginacja), użytkownik ma możliwość sortowania pokazywanych faktur po dacie utworzenia, numerze, kwocie. Gdzie będzie umieszczony kod realizujące to wymaganie? Możesz wskazać palcem na poniższym diagramie:

Obrazek

4) MVP – kwestionujesz istnienie, czy sensowność?
5) Mówiąc o modelu widoku, miałem na myśli klasy reprezentujące dane, które są wykorzystywane podczas prezentacji użytkownikowi, dla jasności na diagramie poniżej jest to nazwane QueryDTO.

Obrazek
Link do wypowiedziLink
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: CQRS czyli co....

Jarek Żeliński:
znowu chyba Jakub ma rację:
czy to nie jest tak, że "jeżeli nie myślimy o implementacji utrwalania to nie ma CQRS"?????

W odnośnikach na stronie Fowlera jest wyjaśnienie autora [wzorca] czym jest, a czym nie jest CQRS. Greg Young wksazuje (http://codebetter.com/gregyoung/2010/02/16/cqrs-task-b..., że jest to po prostu rozdzielenie operacji zmieniających stanu modelu od operacji nie zmieniających stanu modelu (czyli takie przeniesienie zasady CQS z poziomu klasy - osobne metody zmieniające atrybuty i osobne metody odczytujące wartości atrybutów - na poziom usługi)

Samo rozdzielenie nie rozwiązuje żadnego problemu, po prostu daje inne możliwości architektoniczne. Nic nie stoi na przeszkodzie, żeby te rozdzielone interfejsy były dostarczane przez ten sam serwis/klasę, a w przyszłości przez różne serwisy/klasy.

Nie widzę tu sprzeczności z utrwalaniem danych czy brakiem utrwalania.Paweł Grzegorz Kwiatkowski edytował(a) ten post dnia 04.04.12 o godzinie 10:15
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

Ogólnie (w kwestii "Jakub ma rację" i nie tylko) to chyba warto przypomnieć coś co nie raz słyszałem: optymalizować należy tylko to co wiemy po uruchomieniu, że wymaga optymalizacji.

Innymi słowy projektujemy dziedzinę systemu znając oczekiwane "zobowiązania systemu" (który de facto jest realizacją jednej wielkiej klasy ;))) i realizujemy implementację. Jeżeli odkryjemy "braki" w realizacji zobowiązań (np. słaba wydajność) dodajemy do modelu "coś co pozwoli zrealizować nowo odkryte zobowiązania jakościowe".

Tak wiec CQRS w tym kontekście jest, na etapie projektowania implementacji, sposobem realizacji wymagań jakościowych... z tej perspektywy model dziedziny w projekcie PIM nie ulega zmianie, rozbudowujemy model PSM by zrealizować wymagania pozafunckjonalne.
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: CQRS czyli co....

Jarek Żeliński:
Innymi słowy projektujemy dziedzinę systemu znając oczekiwane "zobowiązania systemu" (który de facto jest realizacją jednej wielkiej klasy ;))) i realizujemy implementację. Jeżeli odkryjemy "braki" w realizacji zobowiązań (np. słaba wydajność) dodajemy do modelu "coś co pozwoli zrealizować nowo odkryte zobowiązania jakościowe".

Nie obawiasz się, że jednak takie podejście może nieco wpłynąć na biznes? Zmiana modelu żeby poprawić wydajność, sam nie wiem, nie jestem zwolennikiem takiego podejścia.
Link do wypowiedziLink
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: CQRS czyli co....

Artykuł, który bardzo dobrze wpisuje się w temat - http://www.infoq.com/articles/healthcare-emr-ehr
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

Adrian Chrząstowski:
Jarek Żeliński:
Innymi słowy projektujemy dziedzinę systemu znając oczekiwane "zobowiązania systemu" (który de facto jest realizacją jednej wielkiej klasy ;))) i realizujemy implementację. Jeżeli odkryjemy "braki" w realizacji zobowiązań (np. słaba wydajność) dodajemy do modelu "coś co pozwoli zrealizować nowo odkryte zobowiązania jakościowe".

Nie obawiasz się, że jednak takie podejście może nieco wpłynąć na biznes? Zmiana modelu żeby poprawić wydajność, sam nie wiem, nie jestem zwolennikiem takiego podejścia.

nie zmiana a poszerzenie....(rozbudowa)
Link do wypowiedziLink

konto usunięte

Temat: CQRS czyli co....

1) Wzorzec poprawia wydajność systemu szczególnie w aspekcie prezentacji danych użytkownikowi.

Architekturę tworzy się po to, żeby poprawić wydajność programistów a nie programów.
2) Jaki masz problem z tym podziałem na parę maszyn?

http://codebetter.com/gregyoung/2010/02/16/cqrs-task-b...

"The largest possible benefit though is that it recognizes that their are different architectural properties when dealing with commands and queries … for example it allows us to host the two services differently eg: we can host the read service on 25 servers and the write service on two. "

Greg Young najwyraźniej uważa, że 2 interfejsy i 25 + 1 maszyn da zupełnie inny wynik niż jeden interface i 26 maszyn. A tymczasem wynik (wydajnościowy) będzie ten sam.. no może z tą różnicą, że dwa osobne serwisy trzeba będzie wdrażać dwa razy dłużej niż jeden.
3) Jak Ty rozwiązujesz kwestie prezentowania danych użytkownikowi w swoich aplikacjach, załóżmy że mamy system z Fakturami Jarka, masz repozytorium(FakturaRepozytorium) operujące na grubych encjach (Faktura), logika biznesowa rozsmarowana po elementach modelu domeny. Dostajesz następnie wymaganie: użytkownik ma możliwość wyświetlania faktur, faktury mają być prezentowane po 50 na stronie z możliwością nawigacji pomiędzy stronami(paginacja), użytkownik ma możliwość sortowania pokazywanych faktur po dacie utworzenia, numerze, kwocie. Gdzie będzie umieszczony kod realizujące to wymaganie?

View. Konkretnie w kontrolce wyświetlającej listę. Nawet jeśli takich faktur jest potencjalnie 1000 (co już świadczy o złym projekcie View) to i tak przesyłanie, sortowanie i stronicowanie zajmie nie więcej niż kilkadziesiąt - kilkaset milisekund.
4) MVP – kwestionujesz istnienie, czy sensowność?

Jeśli MVP rzeczywiście w serwisie tworzy konkretne dane dla konkretnych widoków to sensowność.
5) Mówiąc o modelu widoku, miałem na myśli klasy reprezentujące dane, które są wykorzystywane podczas prezentacji użytkownikowi, dla jasności na diagramie poniżej
jest to nazwane QueryDTO.

Pomysł jest głupi. Dlaczego ?

Cechy jakie posiada dobra obiektowa architektura:
- mało kodu
- mała ilość interfejsów i hierarchii
- brak klas / interfejsów poza hierarchiami
- brak specjalizowanych rozwiązań.

W skrócie: dobra architektura to taka która pozwala na szybkie tworzenie banalnego w analizie i rozszerzaniu, niezawodnego kodu.

A teraz popatrzmy sobie na query DTO. To są w zasadzie dwie odrębne aplikacje. W konsekwencji system będzie wymagać napisania dwukrotnie więcej kodu niż w podejściu 'tradycyjnym'.
Będzie w nim dwa razy więcej błędów, będzie powstawać dwa razy dłużej i co najmniej dwa razy dłużej będzie trwać wdrażanie do niego programisty.

A teraz zapytaj się kogoś, czy chce dostać system dwa razy później za dwukrotnie wyższą cenę ale działający 25% szybciej (Bo tak na prawdę to w żadnym razie nie będzie szybszy, dlaczego właściwie miałby być ? Może natomiast być wolniejszy - dane widoków będą obrabiane na serwerze a nie na kliencie)Jakub Wojt edytował(a) ten post dnia 05.04.12 o godzinie 10:19
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: CQRS czyli co....

Wymaganie, które przedstawiłem jest jak najbardziej sensowne, wiec jak zaprojektujesz View, bo nie za bardzo rozumiem:
Jakub Wojt:
Nawet jeśli takich faktur jest potencjalnie 1000 (co już świadczy o złym projekcie View) …

wyjaśnij. Z Twojego rozwiązania wyłania się następujący obraz: Widok pyta repozytorium(nie bezpośrednio) daj mi faktury, a ja je sobie posortuje i podzielę, jeśli się mylę to mnie popraw. Dla aplikacji standalone być może jest to jakieś rozwiązanie, ale dla aplikacji klient-serwer to odpada. Dlaczego grubych encji nie pcha się do widoku nie będę tłumaczył, jest mnóstwo na ten temat w sieci.
Jakub Wojt:
A teraz popatrzmy sobie na query DTO. To są w zasadzie dwie odrębne aplikacje. W konsekwencji system będzie wymagać napisania dwukrotnie więcej kodu niż w podejściu 'tradycyjnym'.
Będzie w nim dwa razy więcej błędów, będzie powstawać dwa razy dłużej i co najmniej dwa razy dłużej będzie trwać wdrażanie do niego programisty.

Oczywiście jest to nieprawda. Kod obsługujący widok w Twoim podejściu też musisz dostarczyć, więc jak wyliczyłeś dwukrotny narzut? Jeśli mi powiesz jak w aplikacjach np. webowych wyświetlasz te grube encje klientowi w przeglądarce to pogadamy o narzucie.Adrian Chrząstowski edytował(a) ten post dnia 05.04.12 o godzinie 11:02
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

A teraz zapytaj się kogoś, czy chce dostać system dwa razy później za dwukrotnie wyższą cenę ale działający 25% szybciej (Bo tak na prawdę to w żadnym razie nie będzie szybszy, dlaczego właściwie miałby być ? Może natomiast być wolniejszy - dane widoków będą obrabiane na serwerze a nie na kliencie)

tu chyba się zapędziłeś, bo
- coś co można szybko napisać bez obiektowej (wzorce) "nadbudowy' będzie kosztowniejsze w utrzymaniu i rozwijaniu niż powtórne może wytworzenie od zera
- co do wydajności: większość klientów zrezygnuje jeżeli się dowie, że zwiększenie wydajności o 10% rodzi koszty większe o 100%

koszt systemu to nie tyle jego pierwotne wytworzenie, co łączny koszt wytworzenia plus kilkuletnie dokładanie nie znanych w dniu wytworzenia funkcjonalności...
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

z klas bo bazy czyli jaki w...




Wyślij zaproszenie do
Anuluj