Architektura powinna być jak miasto. Powinniśmy dobierać odpowiednie style do danej sytuacji. :) Bardzo fajny i wartościowy materiał, poleciała łapka w górę i pozdrawiam!
Ciekawy materia! Fajnie zobaczyć trochę inne spojrzenie na te tematy. Do domeny warto dorzucić jeszcze polityki (Policy), które pozwolą dostoić nam model domenowy jeżeli jest taka potrzeba. Ostatnio też zaczynam doceniać specyfikacje (Specification), które również w pewnych przypadkach fajnie enkapsują nam reguły. Oczywiście tam gdzie ma to sens :)
Jasne, już nie listowałem wszystkiego, żeby nie zaciemniać, bo obstawiam że spora część nie używa tych konceptów, a chciałem żeby materiał był przystępny. Polityki jak najbardziej, bo to w końcu znana i lubiana strategia. Ze specyfikacją mam problem. Czasem też jej używam jeśli się nie da inaczej, ale ogólnie lubię podejście, że model jest zawsze w stanie poprawnym. Specyfikacji też da się używać tak, żeby spełnić to podejście, ale widzę, że niektórzy używają ich jako reguły, których mógłbym nie uruchomić. Dla mnie to błąd, bo niezmienniki powinny być zawsze pilnowane. Jeżeli są różne reguły w zależności od przypadku to warto też się zastanowić, czy to nie inne obiekty, ale czasem specyfikacja ma sens.
Krystian, my teraz w 10cioletnim legacy wydzielamy domeny (powolutku, podczas pisania nowych funkcjonalności) refaktoryzujemy do CQRSa i warstw:D jeszcze trzeba fragment kodu przepisać z zenda1 na laminasa :) ale to przy okazji :)
Super, fajne wyzwanie. Powodzenia. :) Laminas fajny framework, sporo w nim przepracowałem. Z ZF1 nie miałem do czynienia, tylko ZF2/ZF3, ale z tego co wiem ZF1, a ZF2 spora różnica. Później tych zmian nie było aż tak dużo.
Daniel, prowadzę na razie warsztaty tylko z wzorców projektowych OOP. W przyszłości może będzie więcej tematów warsztatowych właśnie związanych na przykład z architekturą, ale na razie chce się skupić na tych które przygotowałem, bo też opracowanie materiałów to sporo pracy.
Co jakiś czas wrzucam coś na YT albo bloga Koddlo.pl. Mogę powiedzieć, że na pewno pojawi się więcej, bo nie planuję przestawać, ale kiedy i co to Ci nie odpowiem. Na pewno polecam Ci skupić się na podejściach, a jak to pożenić w SF to już szczegół implementacyjny. Bardziej skup się na tym, żeby zrozumieć samo podejście. Potem zrobienie tego w jakimkolwiek frameworku wcale nie będzie takie trudne. Oprócz tego jest już masa wiedzy w necie: darmowa i płatna. Ja dokładam od siebie tylko cegiełkę.
Niee, kiedyś miałem jakieś prywatne projekty na githubie, ale to pouswałem bo się trochę zdezaktualizowało. Aktualnie tylko w projektach komercyjnych tego używam. :)
Jeśli mam moduł przykladowo uzytkownik i modu platnosci i używam encji doctrinowych, to jak uniknąć powiązania między tymi domenami kiedy chcę, żeby w bazie byla miedzy nimi relacja?
Bardzo dobre pytanie. Odpowiedź brzmi - bez powiązania modułów się nie da. Ale to dobrze, bo oczekiwałbyś takiego zachowania, że moduły nie są powiązane, a tak naprawdę są tylko mają ukrytą zależność. To o czym mówiłem, są pospinane danymi. Ja uważam, że w pewnym momencie trzeba uciąć obiekt. Nie może być tak, że wychodząc z jakiejkolwiek tabeli w bazie możesz w zasadzie przejść przez całą bazę i wszystko zależy od wszystkiego. Jeżeli powiążesz te encje to i tak się to zemści, bo gdzieś dalej w module też będziesz tej encji używał, nie tylko do relacji. Rozwiązaniem wartym rozważenia jest rezygnacja z relacji tej bazodanowej. Najczęściej robi się to tak, że w module płatności masz obiekt UserId. I tyle, a nie encje User. Trzymasz tylko referencje, potrzebną do identyfikacji co to za użytkownik. Do modelu odczytowego być może też się to przyda. Tak jakby to był zewnętrzny system. To jest rozwiązanie dobre, ale też bardziej skomplikowane bo cześć danych będziesz musiał powielić, synchronizować i propagować. Ale jeśli taką niezależność chcesz utrzymać to trzeba tak podjeść do tematu. Zawsze jak myślę sobie o autonomii, to wyobrażam sobie jakby tego drugiego modułu nie było w tym monolicie tylko był mikroserwisem. Ogólnie, czasem warto iść na kompromisy, żeby zbytnio nie komplikować, ale tak jak napisałem wyżej, to powiązanie i tak bedzie. Zauważ też, że w module płatności to nie jest użytkownik tylko płatnik. Zupełnie inna rzecz, więc nawet warto to zrobić jako inny obiekt, a to że on wyniknie z użytkownika to OK.
Architektura powinna być jak miasto. Powinniśmy dobierać odpowiednie style do danej sytuacji. :)
Bardzo fajny i wartościowy materiał, poleciała łapka w górę i pozdrawiam!
Ciekawy materia! Fajnie zobaczyć trochę inne spojrzenie na te tematy. Do domeny warto dorzucić jeszcze polityki (Policy), które pozwolą dostoić nam model domenowy jeżeli jest taka potrzeba. Ostatnio też zaczynam doceniać specyfikacje (Specification), które również w pewnych przypadkach fajnie enkapsują nam reguły. Oczywiście tam gdzie ma to sens :)
Jasne, już nie listowałem wszystkiego, żeby nie zaciemniać, bo obstawiam że spora część nie używa tych konceptów, a chciałem żeby materiał był przystępny.
Polityki jak najbardziej, bo to w końcu znana i lubiana strategia. Ze specyfikacją mam problem. Czasem też jej używam jeśli się nie da inaczej, ale ogólnie lubię podejście, że model jest zawsze w stanie poprawnym. Specyfikacji też da się używać tak, żeby spełnić to podejście, ale widzę, że niektórzy używają ich jako reguły, których mógłbym nie uruchomić. Dla mnie to błąd, bo niezmienniki powinny być zawsze pilnowane. Jeżeli są różne reguły w zależności od przypadku to warto też się zastanowić, czy to nie inne obiekty, ale czasem specyfikacja ma sens.
Krystian, my teraz w 10cioletnim legacy wydzielamy domeny (powolutku, podczas pisania nowych funkcjonalności) refaktoryzujemy do CQRSa i warstw:D jeszcze trzeba fragment kodu przepisać z zenda1 na laminasa :) ale to przy okazji :)
Super, fajne wyzwanie. Powodzenia. :) Laminas fajny framework, sporo w nim przepracowałem. Z ZF1 nie miałem do czynienia, tylko ZF2/ZF3, ale z tego co wiem ZF1, a ZF2 spora różnica. Później tych zmian nie było aż tak dużo.
Deptrac sztos.
Super odcinek, czy pojawi się więcej ? Lub jakiś kurs? Z chęcią zobaczyłbym kurs do symfony z bardziej zaawansowanymi tematami
Krystian prowadzi warsztaty odnośnie architektury, jeśli dobrze kojarzę :)
Daniel, prowadzę na razie warsztaty tylko z wzorców projektowych OOP. W przyszłości może będzie więcej tematów warsztatowych właśnie związanych na przykład z architekturą, ale na razie chce się skupić na tych które przygotowałem, bo też opracowanie materiałów to sporo pracy.
Co jakiś czas wrzucam coś na YT albo bloga Koddlo.pl. Mogę powiedzieć, że na pewno pojawi się więcej, bo nie planuję przestawać, ale kiedy i co to Ci nie odpowiem.
Na pewno polecam Ci skupić się na podejściach, a jak to pożenić w SF to już szczegół implementacyjny. Bardziej skup się na tym, żeby zrozumieć samo podejście. Potem zrobienie tego w jakimkolwiek frameworku wcale nie będzie takie trudne. Oprócz tego jest już masa wiedzy w necie: darmowa i płatna. Ja dokładam od siebie tylko cegiełkę.
Czesc Koddlo! Bardzo fajny wstep do architektury. Czy posiadasz moze jakis prosty przyklad w zastosowaniu w projecie na repo?
Niee, kiedyś miałem jakieś prywatne projekty na githubie, ale to pouswałem bo się trochę zdezaktualizowało. Aktualnie tylko w projektach komercyjnych tego używam. :)
@@Koddlo Polecasz moze jakies konkretne materialy do nauki tej architektury? Jakies art, czy jakas ksiazke?
@@Koddlo Mozesz nakrecic cos np o mikroservicach albo produktach aws? :) Pozdrawiam
Tak moje. :D Nie no, nie pamiętam nawet z czego ja się tego uczyłem. Nic takiego konkretnego nie zapadło mi w pamięć, ale w sieci jest masa artykułów.
Na ten moment nie planuje tego typu treści, ale w przyszłości - kto wie. :)
Jeśli mam moduł przykladowo uzytkownik i modu platnosci i używam encji doctrinowych, to jak uniknąć powiązania między tymi domenami kiedy chcę, żeby w bazie byla miedzy nimi relacja?
Bardzo dobre pytanie. Odpowiedź brzmi - bez powiązania modułów się nie da. Ale to dobrze, bo oczekiwałbyś takiego zachowania, że moduły nie są powiązane, a tak naprawdę są tylko mają ukrytą zależność. To o czym mówiłem, są pospinane danymi.
Ja uważam, że w pewnym momencie trzeba uciąć obiekt. Nie może być tak, że wychodząc z jakiejkolwiek tabeli w bazie możesz w zasadzie przejść przez całą bazę i wszystko zależy od wszystkiego. Jeżeli powiążesz te encje to i tak się to zemści, bo gdzieś dalej w module też będziesz tej encji używał, nie tylko do relacji.
Rozwiązaniem wartym rozważenia jest rezygnacja z relacji tej bazodanowej. Najczęściej robi się to tak, że w module płatności masz obiekt UserId. I tyle, a nie encje User. Trzymasz tylko referencje, potrzebną do identyfikacji co to za użytkownik. Do modelu odczytowego być może też się to przyda. Tak jakby to był zewnętrzny system. To jest rozwiązanie dobre, ale też bardziej skomplikowane bo cześć danych będziesz musiał powielić, synchronizować i propagować. Ale jeśli taką niezależność chcesz utrzymać to trzeba tak podjeść do tematu. Zawsze jak myślę sobie o autonomii, to wyobrażam sobie jakby tego drugiego modułu nie było w tym monolicie tylko był mikroserwisem.
Ogólnie, czasem warto iść na kompromisy, żeby zbytnio nie komplikować, ale tak jak napisałem wyżej, to powiązanie i tak bedzie.
Zauważ też, że w module płatności to nie jest użytkownik tylko płatnik. Zupełnie inna rzecz, więc nawet warto to zrobić jako inny obiekt, a to że on wyniknie z użytkownika to OK.
tip top