Robicie w firmach ddd+cqrs+event sourcing, czy nadal w php jest to niszowe? Tak przeglądałem oferty pracy z event sourcingiem w wymaganiach i muszę powidzieć, że biednie to wygląda.
@pmichallo98: @tylko_na_dole: Właśnie ciekawi mnie dlaczego tak się dzieje, że mimo, że w tym pracują, to pomijają. Wysłałbym CV do firm, które na takim stacku pracują, a tak to loteria - szukają midów i seniorów, a potem trzeba rzeźbić crudy i api na gołych encjach doctrinowych. Stąd mi się wydaje (podkreślam - wydaje), że to jednak nisza nadal, a przynajmniej, że jest za mało ludzi, którzy to ogarniają w PHP,
@file_get_contents: nie wiem dla mnie mapowanie encji na modele domenowe i potem z powrotem, wszelkie adaptery, data gateway'e to tylko zaciemnianie i komplikowanie kodu. Z ddd to użyteczne mi się wydaje tylko dzielenie apki na konteksty a encje leżą w kontekscie. Czyli w zasadzie modułowość apki a nie ddd... change my mind
@bmLq: To encje (doctrinowe) są modelami, tyle, że używa sie ich roztropniej, czyli np. unika dwukierunkowych relacji i dodaje sie do nich jakieś zachownie poza set get. Inna rzecz, że ORM w modelowaniu domenowym jest raczej kulą u nogi. Sam byłem zawsze raczej sceptycznie nastawiony do ddd, bo właśnie widziałem te absurdy ORMów, typu wiązanie modelu ze strukturą bazy (a wraz z tym samego procesu myślenia) od których nie dało się
No i oczywiście read modele - "select * from tabela, jestem miszczem sql'a" to taki comeback w wielkim stylu ( ͡°͜ʖ͡°)
@file_get_contents: ja to i tak nie lubię pisać ręcznie sqlek, w laravelu korzystam z database managera, całkiem wygodne to, pewnie przy większej skali dopiero bym wrzucił rzeczywiście pdo/sql ale to zawsze możesz dzięki portom i adapterom podmienić sobie implementacje i elo
@Jurigag: Może, ale tu wiele do lubienia nie ma, bo projekcje są już i tak skrojone pod konkretne potrzeby. Można sobie napisać lekką abstrakcję do paginowania i filtrowania. Nie trzeba żadnych DTO, wystarczą arraye, bo obecnie i tak najczęściej musisz "wypluć" jsona z tych danych, zatem oszczędzasz na transformacjach.
@file_get_contents: a to to tak, o ile rzeczywiście tworzy się te projekcie to wtedy spoko :) duża część w cqrs jednak nie robi oddzielnego storagu i struktury w nim dla read modelu tylko wszystko zwracane jest z tej samej tabelki, także taki upośledzony cqrs to jest, coś stojącego między cqs a cqrs bo nadal masz oddzielne interfejsy do odczytu i oddzielne do zapisu ale jednak storage ten sam
@Jurigag: Czyli bez event sourcingu. Mi własnie chodzi o to, jak wiele firm stosuje event sourcing na codzień. CQRS to wiadomo, że już wiele stosuje, tylko właśnie tak upośledzony trochę. ES praktycznie zawsze wdraża się z cqrs. To nie jest nowa technologia, nawet w świecie PHP powstały ze 3 framworki (prooph, broadway i obecnie EventSauce). Nadal jednak nie ma dedykowanych ofert pracy. ES wymaga pewnej zmiany myślania i nie wdraża się
@file_get_contents: ja to osobiście nie lubię tych frameworków do ES bo przez to mój kod domenowy jest przeszyty jakimiś rzeczami z frameworka, ja osobiście uważam że ES powinno się implementować tam gdzie to się przydaje i gdzie będzie z tego wartość dodana - w paru miejscach stosujemy ES, ale w paru miejscach byłaby to sztuka dla sztuki
#php #programowanie
Wysłałbym CV do firm, które na takim stacku pracują, a tak to loteria - szukają midów i seniorów, a potem trzeba rzeźbić crudy i api na gołych encjach doctrinowych. Stąd mi się wydaje (podkreślam - wydaje), że to jednak nisza nadal, a przynajmniej, że jest za mało ludzi, którzy to ogarniają w PHP,
@file_get_contents: ja to i tak nie lubię pisać ręcznie sqlek, w laravelu korzystam z database managera, całkiem wygodne to, pewnie przy większej skali dopiero bym wrzucił rzeczywiście pdo/sql ale to zawsze możesz dzięki portom i adapterom podmienić sobie implementacje i elo