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.
Tworząc skomplikowane systemy bardzo często sięgamy do architektury mikroserwisowej. Im więcej serwisów, tym większa również potrzeba komunikacyjna między nimi. Przyjrzyjmy się zatem jednej z form komunikacji systemów, jaką jest obsługa systemów kolejkowych za pomocą komponentu Symfony Messenger.
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.
Programowanie aplikacji biznesowych, zwłaszcza w języku PHP, bardzo często skupia się na tworzeniu dobrego modelu, odzwierciedlającego domenę aplikacji. Istnieje kilka zasad, które pomagają w utrzymywaniu modelu w dobrej kondycji. W tym wpisie pod lupę weźmiemy jedną z tych zasad, a będzie nią Prawo Demeter.
CQS – (ang. Comand Query Separation) jest to jedną z podstawowych zasad stosowanych w programowaniu obiektowym, której fundamentalną zaletą jest bardzo pozytywny wpływ na czytelność kodu.