Wpis z mikrobloga

@Szubrawski: Sory ale mam zbocznie i DDD rozwijam jako data-driven design czyli takie układanie danych w pamieci aby procesor mógł je przetwarzać uzywająć SIMD w sposób superefektwny. Podejście to wykorzystuje się w zazwyczaj w ECS
  • Odpowiedz
@Szubrawski: CQRS jest bardzo fajny jak zrobiony dobrze - ja raz zrobiłem go dobrze ze swoimi ludźmi i naprawdę 60% resourcow uwolniliśmy bo system kupę czasu tracil na wyliczaniu aktualnego stanu
  • Odpowiedz
@Szubrawski: większość programistów klepie g---o crudy, ale dość duża grupa wali konia do cqrs. W efekcie mamy projekty, które mogłyby być prosto napisane, ale przychodzą jakieś barany i próbują robić overengineering byle mogli się chwalić co to oni nie zrobili w projekcie ostatnim. Pozostają po nich potworki, których potem nikt nie chce ruszać, a biznes trzeba przez dwa lata przekonywać, że trzeba to zaorać i napisać od nowa. Ale jak
  • Odpowiedz
@WyjmijKija: typ zrobi szkolenie z Udemy o cqrs - skoro czytamy i zapisujemy encje to literalnie trzeba zrobić cqrs! A potem zmienia firmę po roku (albo gdy zaczyna się robić nieutrzymywalne) i jest jak mówisz xDD
  • Odpowiedz
@Szubrawski: Jaki CQRS? Taki, że w aplikacji mam jedną bazę i osobne stosy Read oparty o SQL oraz Write oparty o jakiś ORM do niej, czy CQRS w którym mam osobne storage'e na dane do odczytu i dane do zapisu?

Jak pierwszy to często mikropotymalizacja i onanizm techniczny, aczkolwiek w niektórych systemach taki podział się przydawał, tam gdzie ORM nie wyrabiał, a podział aplikacji na mniejsze serwisy, czy wydzielanie osobnych
  • Odpowiedz
@markaron: Dojrzaly CQRS zaklada rozgraniczenie modelu odczytu i zapisu ale agregat nie sluzy wylacznie do zapisu, co jesli masz tam polityki i specyfikacje, odtwarzasz to po stronie read w SQL?
  • Odpowiedz
@Szubrawski: Ja bym powiedział, że dojrzały CQRS zakłada rozgraniczenie storage'u na storage odczytowy i zapisowy. Możesz mieć dwa modele odczytowy i zapisowy w jednej aplikacji i na jednej bazie danych tak jak tutaj https://github.com/kgrzybek/modular-monolith-with-ddd/tree/master/src/Modules/Meetings

Co do odtwarzania czegokolwiek a w szczególności logiki biznesowej po stronie read modelu to nie uważam tego za dobrą praktykę. Takie informacje powinny być już przetworzone. Read model z założenia ma być szybki a do tego
  • Odpowiedz
@markaron: Nie rozumiem stwierdzenia, że CQRS bez osobnych storage'ów to onanizm techniczny, gdzie później sam uzasadniesz czemu to ma sens w przypadku DDD. Chodziło ci o rozwiązanie, gdzie są osobne modele, ale nie ma DDD? Nie słyszałem, żeby ktokolwiek tak robił.
  • Odpowiedz
@markaron: Wiec zakladajac ze masz koszyk zakupowy, na ktory nakladasz rozne polityki zalezne od jego stanu lub aktualnego czasu to, kazdorazowo kiedy dodajesz do niego nowy element, na nowo zapisujesz i przeliczasz caly jego stan, zeby odczyt byl pozbawiony logiki? Co w wypadku jesli agregat nie zostanie wywolany 1 minute po polnocy, a wlasnie zmienila sie polityka? Odczyt koszyka zwroci poprawne dane tak dlugo jak nie wywolasz ponownie agregatu? :)
  • Odpowiedz
@Szubrawski: Trzeba by się nad Twoim wymaganiem zastanowić, ale z doświadczenia (pracowałem przy dwóch różnych e-commercach, jeden duży, drugi trochę mniejszy) i w obu przypadkach stan koszyka był trzymany w bazie danych i jego stan był wyliczany przy zapisie - po zmianie w koszyku (dodanie produktu, wpisanie kodu rabatowego) leciał request do serwera o przeliczenie koszyka i zapisanie jego stanu w bazie. Skąd był następnie odczytywany prostym selectem.
  • Odpowiedz
@Szubrawski Tak zazwyczaj jest jak piszesz z tym koszykiem. O tym, że promocja przestała działać, skończył się jakiś produkt itp. nie dowiesz się poprzez push z serwera a właśnie jak zmienisz zawartość koszyka albo spróbujesz sfinalizować zakupy. Gdybyś chciał jednak jakoś aktualizować ten stan, to imho i tak więcej sensu by miało właśnie przeliczenie na nowo read modelu przez jakiś trigger odpalający write model, a nie dodawanie zasad i przeliczeń przy
  • Odpowiedz
O tym, że promocja przestała działać, skończył się jakiś produkt itp.


@krand: Z drugiej strony to ten problem należy wpierw rozwiązać biznesowo, czyli czy firma może sobie pozwolić na to, że od czasu do czasu zdarzy jej się sprzedać produkt, którego nie ma na stanie lub promocja na niego wygasła?

Niestety, albo i stety większość e-commerców zwłaszcza tych dużych tak działa. Jak sprzedadzą produkt którego nie ma już na stanie
  • Odpowiedz