[Patres]

#java
Kolejne pytanie o architekturę. Czy stosujecie CQRS w swoich projektach?

Oglądałem ostatnio 292. WJUG - Krzysztof Ślusarski "Porty, adaptery, CQRS, Event Sourcing, DDD… w Springu? Świetna prezentacja - bardzo dużo kodu. Jednak przeraża mnie w jaki sposób bardzo prosta aplikacja przemieniła się w potwora która ma tylko 3 zadania: utwórz pracownika, dodaj fakturę, wylicz "wydajność" pracownika. Finalny efekt to ogromna aplikacja: https://github.com/krzysztofslusarski/jug-hex/tree/08-readmodel. Oczywiście widzę zalety: value object, dzielenie aplikacji na domeny a nie service/controller itp. Jednak mam wrażenie, że aż tyle warstw abstrakcji jest mało czytelne i ciężko byłoby mi się połapać w takim projekcie. Idealnie moje odczucie oddaje komentarz z youtube:

chciałem sie przekonać do DDD ale nie potrafie. to jest armata na muche. postawiony fikcyjny problem typu "ktos bedzie chcial nam zmienic stan obiektu przez repozytorium" ktos czyli kto? i kiedy? o jakiej katastrofie mowisz na poczatku projektu? od czego jest code review? kto by taka zmiane przepuscil? te ddd to taki dam bullsht jak soa na poczatku lat 2000. wymarlo to smiercia naturalna bo overhead jaki to narzucalo generowal raczej bol glowy. to samo jest obecnie z mikroserwisami, ze ludzie stosuja to na potege bez myslenia po co to zostalo stworzone i potem maja tone integracyjnych problemow i redundancje danych miedzy bazami. wracajac do ddd: ile razy zmieniales repo w projekcie? 2 lata robimy na postgresie a potem nagle "ej wrzucmy mongo jednak"? dostarczylem ponad 250 ludzi przestrzeni 5ciu lat na setki projektow i nikt w polowie projektow nie zmienial repo. a co jak chcemy zmienic jezyk programowania? a co jak pojawia sie komputery kwantowe? nie widze sensu tego ddd. szmat kodu na fikcyjne problemy. ale sam prowadzacy sztos. merytoryka i wiedza na najwyzszym poziomie. szacunek tutaj :)

[Patres]

Też nie chcę być źle zrozumiany, bo to tak jakbym się spierał, że monolit jest lepszy od microservices bo nie trzeba myśleć o komunikacji miedzy serwisami, wszystko mam w jednym miejscu itp. Jednak przykład z filmiku jest bardzo prostu i mam wrażenie że przy prawdziwych projektach tego kodu będzie jeszcze więcej. Ma ktoś może przykłady realnych projektów które wykorzystują CQRS abym mógł porównać kod i może się do tego przekonać.

[PoteznyMagWody]

@Patres: aritektura hexagonalna - banalne do zaimplementowania, wcale nie dodaje jakos duzo wiecej kodu. DDD - po prostu zacznij dodawac metody do obiektow domenowych zamiast do kazdej #!$%@? pisac serwis lub co gorsza jakis "Helper" xd CQRS imo jest zbędne, event sourcing to zalezy od tego jaki masz problem domenowy

[PaaD]

@Patres: Problem z takimi prezentacjami jest taki, że są one "fajne" dlatego, że zawierają dużo hypowych tematów. Podczas, gdy tak naprawdę nie trzeba ich ze sobą mieszać, nikt tego nie sprawdza ( ͡° ͜ʖ ͡°).

Można używać DDD bez mikroserwisów, event sourcingu. CQRS można uznać za ortodoksyjne wdrożenie zasad SOLID, więc czasem wychodzi trochę samo. Architektura heksagonalna też trochę wyjdzie niemal sama po przestawieniu się na myślenie

[tylko_zerknalem]

@PoteznyMagWody @PaaD: Stosowanie DDD absolutnie nie wymaga programowania obiektowego. Wręcz przeciwnie: bardzo dobrze sprawdza się w wydaniu funkcyjnym, gdzie dąży się do wyraźnej separacji modelu od zachowania. Dostajecie wtedy encje/agregaty które są zdefiniowane zupełnie w oderwaniu od szczegółów implementacyjnych, co z kolei bardzo dobrze uzupełnia się z architekturą heksagonalną (o ile nie jest w ogóle jej dosłownym zaaplikowaniem).

@Patres Każdy z tych buzzwordów trzeba traktować jako narzędzie, które po prostu mamy

[PoteznyMagWody]

@tylko_zerknalem:

#java

w wydaniu funkcyjnym

Skad poznac ze ktos jest fanatykiem programowania funkcyjnego? Sam ci o tym powie ( ͡° ͜ʖ ͡°)

[LazyInitializationException]

DDD - po prostu zacznij dodawac metody do obiektow domenowych

@PoteznyMagWody: Nie na tym polega DDD

[PoteznyMagWody]

@LazyInitializationException: ale latwiej zaczac od tego niz bawic sie w jakies doktoryzowanie w agregaty bo ludzie glupieja i pisza bardzo dziwne kody wtedy, do tego architektura hexagonalna gdzie domena jest w centrum i juz jestes lepszy niz 99% polskich projektow