Jak wygląda kod-spaghetti, wiemy wszyscy. Jest on tworzony bardzo często przez programistów, którzy swoją naukę zakończyli wraz z nauką języka programowania. Próbują oni odkrywać koło na nowo, osiągając coraz to nowsze pokłady nieporządku i niezrozumienia. Dla wszystkich tych, którzy właśnie przeczytali coś o sobie, jest właśnie ten wpis.
Niestety, bardzo często, wybór narzędzia do testów jednostkowych sprowadza się do słów: „Znam PHPSpec, piszmy specki” lub „Wszyscy piszą w xUnit, więc korzystajmy z PHPUnit”. Uważam, że dobrze jest mieć porównanie między narzędziami, dlatego na przestrzeni kilku wpisów postaram się zbadać, w których sytuacjach lepiej jest skorzystać z PHPSpec, a kiedy lepiej wybrać PHPUnit.
Każdy programista, prędzej czy później, zaczyna pisać testy. W większości, wszyscy zaczynają od testów jednostkowych, choć zdarzają się również osoby, które przygodę z testami zaczynają od testów wysokiego poziomu, np. pisanych w behacie. Niestety zdarza się, że programiści pozostają przy tym, czego się nauczyli na początku, ignorując wachlarz zalet pełnego zakresu testowania. Dlatego od dziś, w kilku postach, poruszę temat testów deweloperskich.
Główną rolą Modularnego Monolitu jest przygotowanie aplikacji do ewentualnego wydzielania serwisów z istniejących modułów. Nie zawsze jest to prosty proces, dlatego postanowiłem przyjrzeć się mu nieco bliżej na łamach bloga.
Architektura Warstwowa pozwala świetny w sposób zorganizować nasz kod, dzięki czemu architektura aplikacji przestaje być „płaska”. Dokładając do tego koncept Modularnego Monolitu sprawiamy, że nasza aplikacja zostaje pocięta na kawałki. Można dzięki temu lepiej poznać konteksty aplikacji. Dziś poznamy kolejny wzorzec, który bardzo dobrze wpływa na wymienność części aplikacji – Architekturę Hexagonalną.
Niezależnie od tego, z którego frameworka korzystamy, zawsze powinniśmy promować własną refleksję ponad wszystko. Nawet pracując w Symfony, który uchodzi za najlepsze narzędzie w swojej kategorii, jesteśmy w stanie stworzyć niefajny kod. Dziś poruszymy temat reprezentatywnego przykładu, który potwierdza tą tezę.
Głównym zadaniem architektury opartej o Modularny Monolit jest przygotowanie aplikacji do migrowania w stronę architektury Mikroserwisowej. Jednak zanim podzielimy aplikację na gromadkę serwisów, powinniśmy przemyśleć, w jaki sposób będziemy je ze sobą komunikować. Ponieważ nie jest to łatwe zadanie, przyjrzyjmy się potencjalnym problemom, z którymi możemy spotkać się, kiedy wybierzemy już którąś opcję.
Aplikacje oparte o Modularny Monolit są swego rodzaju majstersztykiem – łączą w sobie zalety aplikacji monolitycznych (znane ludzkości od dawna) oraz wnioski z trudnej pracy na mikroserwisach. Jest to jedno z bardziej odpowiedzialnych podejść, na wyjaśnienie którego stanowczo warto poświęcić tutaj chwilę.
Umiejętność praktycznego korzystania z wzorców projektowych jest czymś, co spłaca się bardzo szybko. Wzorce właśnie po to są – aby rozwiązywać problemy, z którymi się spotykamy na co dzień, bez odkrywania koła na nowo. Spójrzmy zatem na dwa świetnie pracujące ze sobą wzorce – fasady i strategii – w oparciu o dosyć standardowy scenariusz biznesowy.
Ukoronowaniem Domain Driven Design, jak sama nazwa wskazuje, jest domena. Na bardzo wstępnym etapie wiedzy ta warstwa kojarzy się zazwyczaj z encjami przepełnionymi dużą liczbą setterów/getterów. Poznajmy zatem czym jest oraz jak powinna wyglądać warstwa domenowa aplikacji opartej o DDD.