Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
No comments yet. Be the first to comment.
W świecie nowoczesnych architektur oprogramowania, zwłaszcza tych opartych o mikrousługi, komunikacja asynchroniczna jest jak system nerwowy – kluczowa dla funkcjonowania całości. Jednak, aby ten system działał sprawnie, musimy posługiwać się precyzyjnym językiem. Dwa fundamentalne pojęcia, które często bywają mylone, to komenda (command) i zdarzenie (event).
Zrozumienie różnicy między nimi oraz tego, kto jest "właścicielem" każdego typu komunikatu, to jeden z najważniejszych kroków do budowy elastycznych i skalowalnych systemów. Zanurzmy się w ten temat.
Komenda to dyrektywa. To prośba o wykonanie konkretnej akcji, która ma zmienić stan systemu w przyszłości.
Intencja: "Zrób coś!"
Charakter: Jest imperatywna i skierowana do jednego, konkretnego odbiorcy. Nadawca wie, od kogo oczekuje wykonania zadania.
Nazewnictwo: Używa trybu rozkazującego, np. ZarejestrujUżytkownika, DodajProduktDoKoszyka, WyślijFakturę.
Wynik: Może zostać zaakceptowana lub odrzucona. Odbiorca ma prawo odmówić wykonania komendy, jeśli np. narusza ona reguły biznesowe (próba rejestracji na zajęty e-mail).
Właścicielem komendy jest jej konsument (odbiorca). To on definiuje, jakie operacje potrafi wykonać i jakich danych do tego potrzebuje. Publikuje niejako swoje API w postaci komend, które akceptuje.
Analogia: Wysyłając komendę, jesteś jak szef, który daje swojemu pracownikowi (konsumentowi) konkretne polecenie (
PrzygotujRaportSprzedaży). Pracownik wie, co ma zrobić, ale może też odpowiedzieć: "Nie mogę tego zrobić, brakuje mi danych za ostatni kwartał".
Zdarzenie to powiadomienie o fakcie, który już miał miejsce. Jest to zapis zmiany stanu, która dokonała się w przeszłości.
Intencja: "Coś się właśnie stało!"
Charakter: Jest opisowe i rozgłaszane do wszystkich zainteresowanych (lub do nikogo). Producent zdarzenia nie wie, kto i czy w ogóle ktoś go słucha.
Nazewnictwo: Używa czasu przeszłego, np. UżytkownikZarejestrowany, ProduktDodanyDoKoszyka, FakturaWysłana.
Wynik: Jest faktem dokonanym, więc nie może zostać "odrzucone". Subskrybenci po prostu na nie reagują.
Właścicielem zdarzenia jest jego producent (wydawca). To on jest źródłem prawdy o tym, co wydarzyło się w jego domenie i to on decyduje, jakie informacje zawrzeć w komunikacie.
Analogia: Publikując zdarzenie, jesteś jak agencja prasowa, która podaje do wiadomości publicznej komunikat (
TrzęsienieZiemiWykryte). Różne służby (subskrybenci) – straż pożarna, pogotowie, sejsmolodzy – mogą na tę informację zareagować, każda na swój sposób. Agencja nie kieruje komunikatu do żadnej z nich bezpośrednio.
Komenda (Command) | Zdarzenie (Event) | |
Intencja | Nakazanie akcji | Poinformowanie o fakcie |
Czas | Przyszłość (“zrób”) | Przesłość (“stało się”) |
Adresat | Jeden konkretny odbiorca | Zero lub wielu odbiorców |
Własność | Konsument (odbiorca) | Producent (wydawca) |
Sprzężenie | Ścisłe (nadawca zna odbiorcę) | Lużne (nadawca nie zna odbiorców) |
Prawidłowe rozróżnienie komend i zdarzeń oraz respektowanie zasad ich własności pozwala budować systemy, które są:
Autonomiczne: Każdy serwis może rozwijać się niezależnie, o ile nie łamie zdefiniowanych kontraktów.
Elastyczne: Łatwo możemy dodawać nowe serwisy, które reagują na istniejące zdarzenia, bez modyfikowania starych komponentów.
Odporne na błędy: Awarie w jednym z subskrybentów zdarzenia nie wpływają na pracę producenta ani innych subskrybentów.
Opanowanie tej koncepcji to fundament dla zaawansowanych wzorców architektonicznych, takich jak CQRS (Command Query Responsibility Segregation). To nie tylko teoria – to praktyczna wiedza, która procentuje czystszym kodem i stabilniejszymi aplikacjami.
