Projekt TheGame #1 – Inicjalizacja i konfiguracja środowiska

Każdy ma w głowie projekt życia – takie coś, co chcielibyśmy napisać, jeszcze niewiele potrafiąc. Próbujemy raz, drugi raz, aż w końcu się poddajemy, bo wyszło… beznadziejnie. Ja od dzisiaj zaczynam swój projekt życia, którego postępy możecie śledzić na Githubie 🙂

Motywacja

Robiąc taki projekt, jest potrzebna motywacja – coś, co pozwoli nam wracać co chwilę do tematu z nowymi pomysłami. Bez mocnej motywacji może się okazać, że zostawimy projekt w połowie. Moja motywacja składa się na kilka elementów:

• Chciałbym popisać sobie coś w DDD (szczególnie korzystając z elementów taktycznych).
• Projekt dawno włożony do szuflady od kilku miesięcy (ponad pół roku) wraca do mnie jak bumerang.
• Chciałbym podzielić się z Wami tym, w jaki sposób można pisać zgodnie z zasadami DDD, a to jest odpowiednia okazja.

Wszystko to, to są takie elementy, które składają się na motywację średniego kalibru. Może ten ostatni punkt jest mocniejszy, bo bardziej wiążący ze względu na Was – czytelników, oraz da mi mnóstwo frajdy, jeżeli będziecie również włączali się w ten projekt na Githubie. No ale oprócz tego jest coś, co powoduje, że chciałbym mocno, aby tym razem wypaliło.

Kilka lat temu rozmawiałem z kumplem, który programował już ponad 20 lat i podzielił się ze mną tym, że przez całe życie chciał napisać grę w 3D. Dla niektórych może okazać się to śmieszne, bo miały to być zwykłe Kierki. Powiedział mi, że jest blisko powrotu do tematu, bo coraz mocniej to do niego wraca. Niestety – po kilku miesiącach od tego czasu – zmarł. Również niestety – projektu nie zaczął. I to jest moja główna motywacja – zrobić to, kiedy jeszcze mogę. Kiedy jeszcze chcę. Bo kiedyś albo nie będę mógł, albo już nie będę chciał.

Projekt TheGame – czyli że co?

Dosyć smędzenia, teraz do rzeczy. Graliście kiedyś w OGame? a w XWars? A może SpacePioneers (tu akurat nie mam linka)? Nie? No to mieliście szczęśliwe życie. Bo ja byłem swojego czasu mocno uzależniony od tych gier.

Gra, którą chcę stworzyć ma być webową grą strategiczną o tematyce kosmicznej. Startujemy z jedną planetą, na której zbieramy surowce, za które budujemy budynki, budowle obronne, flotę statków i naparzamy się tymi statkami z innymi graczami. Dodatkowo możemy osiedlać nowe planety, zawierać oficjalne sojusze oraz pomagać sobie wzajemnie. W zasadzie, to jest to pełny zarys konceptu, który chciałbym osiągnąć.

Plan działania

Jak pewnie się domyślacie, robimy Modularny Monolit. Na początku będziemy tworzyć pojedyncze moduły, które będą komunikowały się ze sobą przez serwisy-bridge oraz zdarzenia. Każdy z modułów będziemy testować na poziomie jednostkowym (PHPSpec oraz PHPUnit) oraz integracyjnym (PHPUnit).

Kiedy już zrobimy już kilka komponentów, które mogłyby już jakoś ze sobą pracować, to wtedy skleimy to sobie w kontrolery i będziemy pisać testy funkcjonalne oraz end2end. Jeszcze nie podjąłem decyzji, czy będziemy robić to w GUI za pomocą Twiga, czy wystawię odpowiednie API. I w zasadzie w taki sposób chyba powinno się budować aplikację w DDD: warstwa interfejsu użytkownika nie jest najważniejsza. No dobra, jest ważna, ale nie w tej chwili i nie dla mnie. Jak zostanie podjęta decyzja co do warstwy interfejsu, to wtedy będziemy pisać testy w Behacie.

Zarys architektury

Jeżeli mowa o architekturze naszego monolitu, to jest pewien wzór, do którego będę próbował mocno się dostosować. Ten wzór opisany jest we wpisie Herberto Graca: DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together. Bardzo zachęcam Was do zapoznania się z tym wpisem. Po mocnej analizie tego, co napisał Herberto, mój świat programistyczny stał się inny, lepszy.

Dla tych, co nie chcą za bardzo kopać, zamieszczam obrazek przedstawiający pełną architekturę (mam nadzieję, że Herberto się nie obrazi ?):

Swoją drogą, jakiś czas temu miałem ten obrazek odpalony na drugim monitorze, aby móc się w niego wpatrywać i próbować zrozumieć każdy z jego elementów. Oczywiście, udało się mi pojąć, o co tam chodzi 🙂

No to zaczynamy! 🙂

Projekt zaczynam standardowo, od postawienia aplikacji Symfony oraz zainstalowania PHPSpeca i PHPUnita, ECSa i PHPStana. Co do wersji Symfony, to bardzo chciałbym zacząć od najnowszej wersji long-term, czyli 6.4. Niestety, ale ta wersja wychodzi dopiero w listopadzie, czyli za mniej więcej miesiąc czasu. Dlatego zacznę od wersji 6.3 licząc się z tym, że zaraz będę musiał ją podnieść do 6.4, aby mieć wersję long-term.

Podsumowując; narzędzia, z których będę korzystał:

• Symfony 6.3 short-term (docelowo Symfony 6.4 long-term)
• EasyCodingStandard – reformat kodu
• PHPStan – statyczna analiza kodu (poziom 8)
• PHPSpec – testy jednostkowe związane z flow biznesowym (BDD)
• PHPUnit – testy jednostkowe związane z kalkulacjami, testy integracyjne (repozytoria, obsługa komend itp.)

Do całości dokładam GithubActions, które dla projektów open-source jest narzędziem darmowym. Będzie ono budowało i testowało aplikację z każdym pushem do repozytorium. Szczególnie pomocne to jest, kiedy ktoś tworzy pull-requesta i chce zobaczyć, czy wszystko śmiga.

Link do repozytorium: https://github.com/senghe/TheGame ✨

Serdecznie zachęcam Was do gwiazdkowania oraz udzielania się, jeżeli będziecie mieli jakieś pomysły. Z chwilą publikacji tego wpisu możecie spodziewać się w repozytorium z czystym Symfony oraz z powyższymi narzędziami, skonfigurowanymi wstępnie pod projekt.

Który moduł na start?

Wydaje mi się, że największą uwagę na początku skupi moduł (ej, wolę nazwę komponent…) Resources. Jest to komponent, który wydaje się być bardzo samodzielnym, od którego mogą być potencjalnie uzależnione inne komponenty. Dlatego jego istnienie od samego początku może być kluczowe.

O konstrukcji oraz wszystkich konceptach, które będę chciał wykorzystać w komponencie Resources, będzie następny wpis.

Także tego, życzcie powodzenia i do kolejnego wpisu! 🙂