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ę.
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.
Każdy komercyjny system, który odniósł biznesowy sukces, kiedyś rośnie. Istnieje jednak jedna, bardzo popularna pułapka, która z czasem powoduje zmianę aplikacji w ogromnego kolosa, z którym jest ciężko pracować; jest to brak jakichkolwiek warstw w systemie, nazywany przeze mnie architekturą płaską.
W trakcie działania aplikacji biznesowych niejednokrotnie wiele się dzieje. Wielokrotnie zmieniamy stan systemu, o czym dobrze by było np. poinformować inne systemy bądź wysłać maila. Jednym, z bardzo dobrych do tego celu wzorców, jest architektura sterowana zdarzeniami, o której właśnie będzie ten wpis.
Chyba każdy, kto zaczynał pracować na dowolnym frameworku MVC, popełniał ten sam błąd: znaczną część logiki zamieszczał wewnątrz akcji kontrolera. Efektem tego były pliki kontrolerów o dużej ilości linijek. W dzisiejszym wpisie rozważymy wzorzec, dzięki któremu zadbamy nieco o nasz kod tak, aby duże kontrolery do nas więcej nie wróciły. Mowa oczywiście o wzorcu CQRS.