Wpis z mikrobloga

Jest podchwytliwe, bo przeciętny zjadacz encji na dzień dobry powie, że Post posiada Komentarze, więc to relacje 1:n.

Ktoś z dobrą wiedzą od razu zaznaczy, że taka relacja, mimo, że się narzuca jest błędna i przedstawi jakąs rozsądną alternatywę.


@file_get_contents: Albo jestem głupi, albo moja nietrzeźwość mnie zamroczyła, ale - dlaczego taka relacja jest błędna i jaka alternatywa będzie OK?

@axelrodi: Gdy modelujesz domenę, to zadajesz sobie pytanie, czy Post musi mieć "świadomość", że istnieją do niego komentarze? Najcześciej nie musi. Może istnieć bez komentarzy. Drugie pytanie jakie można zadać, to czy napewno każdy komentarz należy do postu. Też nie musi, bo możesz być komentarzem do Fotek, a nawet do innych komentarzy. To prowadzi do wniosku, że koncept Komentarza jest bardziej generyczny - istnieje jakiś zasób, z którym Komentarz jest luźno
@file_get_contents: Jak to nie mogę mieć publicznych setterow w każdą stronę ( ͡° ͜ʖ ͡°)? Powiedzenie że post może mieć komentarze nie jest złe. Od systemu zależy czy komentarz może mieć inne komentarze albo być związany z innym zasobem. Na uml będzie to jakaś forma kompozycji zapewne bo raczej nie można mieć tego samego komentarza do wielu zasobów a zawsze do jednego(inny komentarz, post, zdjęcie, cokolwiek). Kwestia
Powiedzenie że post może mieć komentarze nie jest złe.


@Whiskeyjack29: Tak na poziomie rozmów z biznesem to owszem, ale modelarz i tak powinien drażyć temat, bo "Commantable" może być więcej zasobów i trzeba to jakoś przełożyć na konkretną architekturę. Ta domena jest co prawda trywialna, ale rozważ taką sytuację, że zajmują się tym 2 zespoły programistów. Każdy z tych zespołów pracuje niezależnie i ten od Komentarzy zajmuje się tylko ich własnym
@Whiskeyjack29: Możesz podać przykład wykorzystania takiego drzewa przy codziennej pracy programisty? Nawet nie chodzi mi o przykłady których jest wiele na internecie z numerkami, tylko takie z życia wzięte dzięki, którym zastosowanie drzewa z danym przypadku było bardzo optymalne. @Stettinboi: możesz podesłać na priv to zadanie?
Tyle, że to nie jest wina podejścia DDD, tylko słabego poziomu wiedzy, a przede wszystkim braku wyobraźni. W klasycznych podejściach z jakimis entity frameworkami używającymi lazy loadingu, to też baza będzie zasrana requestami ( ͡° ͜ʖ ͡°)


@file_get_contents: no i widzisz, dokładnie widać po tym co mowisz, ze nie rozumiesz nawet o co mi chodziło, bo rozmawiamy z zupełnie innej pozycji i z zupełnie innych światów ;)
@bruce: Nie wchodząc w jakieś ciekawe przypadki zastosowań na niższym poziomie to wiele hierarchi które można spotkać w systemach enterprise modeluje się za pomocą drzewa np. Struktury organizacyjne firmy, planowanie wydatków w jednostkach organizacyjny firmy, modelowanie sytuacji że urządzenia mają swoje komponenty a te komponenty kolejne komponenty, modelowanie przepływów pracy (grafy) i jeszcze długo można wymieniać. Nie jest to jakieś święto, ze się widzi drzewo, no chyba że się klepie CRUDy
@alex-fortune: Ja to rozumiem, choć nie praktykuję (co słuszne zauważyłeś profilując mnie). Staram się raczej te rozmowę kierować na tory bardziej ogólno-projektowe, niż na samą wydajność. Widzisz, jeśli zrobię słaby algorytm, to właśnie tacy ludzie jak Ty to wychwycą i poprawię - praca zespołowa. To szczegół implementacyjny, a jak cały projekt jest napisany w sposób chaotyczny, nieskalowalny, to problem robi się większy. Inna rzecz, że w PHP tablice mamy zaimplementowane jako
Pobierz filegetcontents - @alex-fortune: Ja to rozumiem, choć nie praktykuję (co słuszne zauw...
źródło: comment_1649497586ZVlyXgNr3NtHVglKTxUiL3.jpg
Widzisz, jeśli zrobię słaby algorytm, to właśnie tacy ludzie jak Ty to wychwycą i poprawię - praca zespołowa.


@file_get_contents: nie jestem od tego by poprawiać za Tobą podstawowe problemy, chyba że jesteś internem i się dopiero uczysz ;)

Generalnie problem z programistami z backgroundem podobnego do Twojego - a wiem, bo sam mam taki background, uczyłem się sam, zaczynałem w PHPie i interesowały mnie identyczne rzeczy co Ciebie, a o DDD
@alex-fortune: bodajże Seliga miał na takich fajną nazwę - architekt astronauta. Jest tak wysoko, że ziemi nie widzi a i tlenu mu brakuje.
Tacy potrafią przechrzanić 3h spotkanie na dyskusję o tym czy post zawiera komentarze czy tylko ich używa.

Prawde mówiąc sam bym pewnie nie zdał tego interview, bo bym zaproponował, że jednak post zawiera komentarze i zrobiłbym to tak, aby jednym stuknięciem w bazę pobrać cały post z komentarzami
Wbrew pozorom olanie takich aspektów na etapie projektowania potem kończy się tym że zamiast jednej taniej instancji wirtualnej potrzebny jest klaster dedyków.


@Krolik: Jak to mówi święta zasada, all non-trivial abstraction is leaky ;) Tym bardziej myślenie tylko o kodzie robi się w pewnym momencie niebezpieczne. ( ͡° ͜ʖ ͡°)
Takie podejście sypie się, kiedy skala zaczyna się robić poważna tudzież jeśli Twój system wykracza poza standardowe ramy "weź request, przemiel, wypluj odpowiedź"


Ile jest takich systemów? Dalej - ile w tych systemach tak naprawdę jest tej zaawansowanej logiki? Ja Ci powiem tak. Zgadzam się, że każde podejście ma wady i zalety. Nikt jednak nie proponuje używania technik przeznaczonych dla biznesu w grach komputerowych, czy w modelach klimatycznych, bo to byłby absurd.
@file_get_contents: Ale wiesz, że poważne bazy danych nie ładują całego wyniku do pamięci i potrafią w paging? I 10k rowków to jest pikuś, to są milisekundy. Przesłanie 10k rowkow będzie trwało mniej niż samo stuknięcie do serwera i przygotowanie planu zapytania.

I tyle jest warta Twoja papierowa wiedza o modelowaniu w oderwaniu od sprzętu. Modelowanie danych powinno się różnić zawsze w kontekście konkretnego systemu baz danych i zlecać osobom które rozumieją
@Krolik: Sorry, ale po pierwsze, to wydaje mi się, że jednak trochę uczysz ojca dzieci robić, do tego z tonem wyższości. Po drugie. Rozmowa jest głównie o modelach w języku, a nie o bazach. Po trzecie:

Modelowanie danych powinno się różnić zawsze w kontekście konkretnego systemu baz danych


Wiesz co, no można i tak podchodzić do tematu, ale moje doświadczenia wskazują na klapę w przypadku programów, które po prostu rosną. Tak
@file_get_contents:

Rozmowa jest głównie o modelach w języku, a nie o bazach


W pamięci to możesz mieć te same dane reprezentowane w różny sposób i nie ma tu żadnej jednoznacznie dobrej odpowiedzi, poza ogólnym - im prościej tym lepiej oraz jak najdalej od OOP (zwłaszcza OOP w stylu lat 90-tych z wielkimi hierarchiami klas, dziedziczeniem i masą referencji między bytami).

Dlatego dopóki nie podasz pełnego kontekstu zadania, to takie pytania czy
im prościej tym lepiej oraz jak najdalej od OOP (zwłaszcza OOP w stylu lat 90-tych z wielkimi hierarchiami klas, dziedziczeniem i masą referencji między bytami).


@Krolik: No widzisz, sam wskazujesz na bolączki wadliwego zaprojektowania modelu. Dokładnie to jest jednym z celów DDD - redukcja powiązań między bytami.

Klapa w przypadku podgramow które rosną wynika najczęściej z łamania przyjętych abstrakcji i robienia hacków bez zastanowienia, a nie w wyniku stosowania struktur danych
Ile jest takich systemów? Dalej - ile w tych systemach tak naprawdę jest tej zaawansowanej logiki?


@file_get_contents: zalezy gdzie pracujesz, u mnie bardzo dużo. I na drugie pytanie - też bardzo dużo.

Co do event sourcingu - trochę demonizujesz wydajnościowe implikacje.


@file_get_contents: mówiłem Ci, rozmawiamy o innej skali. ;) I zresztą tak jak też mówiłem, rozumiem skąd jest Twoje podejście, bo "byłem w Twoim świecie", ale Ty jeszcze najwyraźniej nie