I’ll keep saying this … if people can’t build monoliths properly, microservices won’t help.

Simon Brown

Cześć 

To jest kolejny artykuł z serii wzorców o architekturach aplikacyjnych. Poprzednie artykuły znajdziesz pod tym linkiem mini-seria wpisów.

W dzisiejszym artykule:

• Czym jest architektura mikroserwisów
• Topologie mikroserwisów
• Wady i zalety architektury

Czym jest architektura mikroserwisów

Mikroserwisy to styl architektoniczny, w którym pojedyncza aplikacja jest tworzona jako zestaw małych usług. Każda usługa działa w ramach własnego procesu i jest – albo przynajmniej powinna być – niezależna od innych. Warto podkreślić, że mikroserwis to nie jest zawsze pojedyczny projekt (moduł). W ramach jednego mikroserwisu możemy mieć kilka projektów (modułów), które tworzą jeden niezależny mikroserwis. Całkiem dobrze obrazuje to poniższy rysunek.

Wracając do niezależności – co dokładnie miałem na myśli? Każdy z serwisów powinien móc być wdrażany/testowany całkowicie oddzielnie od pozostałych usług. Tylko wtedy osiągniemy pełnię korzyści z tej architektury!

Mikroserwisy są implementacją wzorca SOA (Service-Oriented Architecture) z tą różnicą, że usługi mikroserwisowe są rozbijane na mniejsze – łatwiejsze do ogarnięcia. Zamiast monolitycznej aplikacji otrzymujemy N niezależnych, które mogą być rozwijane niezależnie przez kilka odrębnych zespołów.

Podsumowując, charakterystykę mikroserwisów można zamknąć w kilku punktach:

• jest implementacją wzorca SOA
• nie ma punktów centralnych, które orkiestrują powiązaniami pomiędzy serwisami (poszczególne usługi same wiedzą w jaki sposób komunikować się z innymi)
• komponenty są luźno powiązane
• najlepiej nadaje się do chmury (tam wyciągnie największe korzyści – skalowalność)

Topologie mikroserwisów

Architekturę mikroserwisów można podzielić na 3 główne topologie: API REST, Application REST i centralized messaging topology.

API REST – charakteryzuje się 'drobnoziarnistymi’ (fine-grained) mikroserwisami. Oznacza to, że mikroserwisy są małe i wykonują konkretne zadanie biznesowe niezależnie od pozostałych mikroserwisów. Topologia przydatna dla stron internetowych, które udostępniają małe, niezależne, indywidualne usługi za pośrednictwem API.

Application REST – topologia typowa dla małych i średnich aplikacji biznesowych o stosunkowo niskim stopniu złożoności. Komponenty (moduły) usług różnią się od tych w topologii opartej na API-REST tym, że zwykle są większe (coarse-grained) i reprezentują niewielką część całej aplikacji biznesowej, a nie drobnoziarnistą, pojedynczą usługę.

Centralized messaging topology – jest podobna do Application REST, z tym wyjątkiem, że zamiast używać REST’a do komunikacji, używa lekkiego scentralizowanego brokera komunikatów (ActiveMQ, RabbitMQ, inna implementacja JMS). Scentralizowana topologia przesyłania wiadomości jest zwykle stosowana w większych aplikacjach biznesowych. Zalety to zaawansowane mechanizmy kolejkowania, asynchroniczne przesyłanie komunikatów, monitorowanie oraz lepszy load balancing i skalowalność.

Wady i zalety architektury

Zalety:

• serwisy są małe i niezależne – a zatem łatwiejsze w rozwoju i zrozumieniu
• łatwiejsza testowalność (mowa tylko o pojedynczym mikroserwisie)
• możliwość niezależnego wdrażania (przynajmniej w teorii tak powinno być)
• izolacja błędów – dzięki temu, że serwisy są od siebie niezależne, w przypadku gdy wystąpi błąd (np. wyciek pamięci) w jednym z serwisów nie powinno to wpłynąć na działanie innego
• pozwala na użycie dowolnej technologi w nowych serwisach (może to być również wadą)
• skalowalność (szczególnie zauważalne w technologiach chmurowych)

Wady:

• dowolność technologiczna może prowadzić do chaosu
• testowanie interakcji pomiędzy serwisami jest utrudnione
• skomplikowana infrastruktura
• utrudniona analiza komunikacji
• IDE/narzędzia developerskie wciąż nie wspierają tak dobrze projektów opartych o mikroserwisy jak projektów monolitycznych

Podsumowanie

Decyzja o tym czy nowy projekt powinien iść w stronę mikroserwisów powinna być odraczana możliwie jak najdłużej. Bardzo często zamiast iść w kierunku mikroserwisów (bo są popularne) powinniśmy zacząć od monolitu. Wyjątkiem będzie naprawdę dobrze przemyślana architektura i wizja na przyszłość, gdzie od razu wiemy, że prędzej czy później mikroserwisy faktycznie przyniosą nam korzyści.

Mikroserwisy to fajna architektura. Ale należy pamiętać – dobór architektury zawsze powinien być podyktowany problemem biznesowym. Nasze ego czy też chęć cv-driven-development nie powinno zwyciężać bo może się okazać, że zatopimy projekt.

Źródła:

• Software Architecture Patterns (Mark Richards) – Chapter 4. Microservices Architecture Pattern
• Pattern: Microservice Architecture
• Microservices
• Java Microservices: A Practical Guide

Za tydzień

Wejdziemy w świat DDD. Zaczniemy od poznawania fundamentów

Artykuł Architektura mikroserwisów pochodzi z serwisu bdabek.pl.

Cześć 

To jest już trzeci wpis z mini-serii blogów o architekturach aplikacyjnych. W poprzednich wpisach mogłeś przeczytać o

• • architekturze warstwowej
  • architekturze sterowanej zdarzeniami
  • architekturze mikrojądra

W dzisiejszym artykule dowiesz się:

• Czym jest architektura hexagonalna
• Jak wygląda struktura hexagonu
• Wady i zalety architektury

Czym jest architektura hexagonalna

Celem architektury hexagonalnej jest umożliwienie, aby aplikacja którą rozwijamy była traktowana tak samo przez użytkowników, programy zewnętrzne, testy czy też skrypty. Dodatkowo ma ona umożliwiać rozwój i testowanie aplikacji w oderwaniu od zewnętrznych zależności (baza danych / zewnętrzne API).

Architektura hexagonalna w centrum aplikacji stawia na przypadki użycia i domenę – to też jest powód dlaczego sprawdza się ona dobrze z DDD. Warto zauważyć, że ten styl architektoniczny jest przeciwny architekturze wartstwowej – tutaj zależności są kierowane do środka domeny a nie jak w przypadku warstw od góry do dołu.

Nazwa architektury wzięła się z efektu wizualnego jaki przedstawia hexagon – więcej o tym przeczytasz w artykule Alistair’a Cockburn’a, twórcy architektury:

The hexagon is not a hexagon because the number six is important, but rather to allow the people doing the drawing to have room to insert ports and adapters as they need, not being constrained by a one-dimensional layered drawing. The term ‘’hexagonal architecture’’ comes from this visual effect.

Jak wygląda struktura hexagonu

Hexagon składa się z trzech kluczowych elementów: domeny (core), portów i adapterów. Jeżeli spojrzymy na hexagon zaprezentowany na rysunku powyżej można też zauważyć, że nasz core (domena i przypadki użycia) używają portów – czyli domena wie na co dany port pozwala, np. zapis użytkownika ale nie wie jak to się stanie. I do tego właśnie służą adaptery. Aplikacja może mieć np. prawdziwą bazę danych, która rzeczywiście zapisze użytkownika w bazie ale może to też być hashmapa, która po restarcie aplikacji nie będzie już niczego pamiętać.

Porty dzielą się na wejściowe i wyjściowe. Wejściowe to te, które sterują naszą logiką np. GUI, gdzie użytkownik wywołuję daną akcję. Wyjściowe są używane (sterowane) przez logikę biznesową. Tutaj najlepszym przykładem są bazy danych i zewnętrzne API. Aplikacja musi porozumieć się z jakimiś zewnętrznymi komponentami i w tym celu używa właśnie portów wyjściowych.

Domena

Są to nasze obiekty domenowe. Ich implementacja powinna być na tyle jasna, żeby nawet ktoś nie techniczny mógł podejść i powiedzieć ok, rozumiem co tu się dzieje. Obiekty domenowe nie powinny mieć żadnych zewnętrznych zależności. Domena opisuje jak coś zrobić.

Przypadki użycia

To klasy, które obsługują konkretne problemy biznesowe. Jest to faktyzcna wartość dla biznesu, która rozwiązuje ich problem. Przypadki użycia mogą zawierać wszystkie niezbędne walidacje i logikę reguł biznesowych, które są specyficzne dla konkretnego przypadku użycia (dlatego też nie mogą być implementowane w obiektach domeny) a następnie delegują pracę do domeny. Use case’y nie są zależne od zewnętrznych komponentów, natomiast jeżeli potrzebują czegoś z zewnątrz (np. pobranie użytkownika) to tworzą do tego port (albo używają istniejącego). Przypadki użycia mówią co zrobić.

Porty wejściowe i wyjściowe

Porty możesz sobie wyobrażać dokładnie tak jak porty w komputerze, np. USB. Nie jest ważne czy podłączysz urządzenie firmy X czy Y – oba powinny działać.

W architekturze hexagonalnej komunikacja do i z aplikacji odbywa się przez porty. Port wejściowy będzie zazwyczaj interfejsem, który jest implementowany przez konkretny przypadek użycia. Podobnie jest z portem wyjściowym – to również będzie interfejs. Tym razem jednak przypadek użycia będzie go używał – a nie tak jak w przypadku portu wejściowego implementował.

Dzięki portom wejściowym i wyjściowym mamy bardzo wyraźne miejsca, w których dane wchodzą i wychodzą z naszego systemu, ułatwiając rozumowanie na temat architektury.

Adaptery

Adaptery tworzą zewnętrzną warstwę architektury hexagonalnej. Nie są częścią rdzenia, ale wchodzą z nim w interakcję. Adaptery również dzielimy na dwie grupy: wejściowe i wyjściowe. Wejściowe (lub sterujące) wywołują porty wejściowe, aby coś zrobić w aplikacji – w końcu wywołują konkretny przypadek użycia. Wyjściowe (sterowane) są natomiast wywoływane przez przypadki użycia.

Adaptery ułatwiają wymianę określonej warstwy aplikacji, np. zmiana bazy danych na inną. Wystarczy napisać tylko nowy adapter.

Wady i zalety architektury

Zalety:

• • testowalność
  • rozwijalność i utrzymanie
  • wymiana technologii

Wady:

• • trudniejsza nawigacja po kodzie źródłowym – musimy ogarniać co, gdzie jest używane
  • wiele adapterów = wiele testów

Podsumowanie

W tym krótkim wpisie chciałem przedstawić Ci ideę architektury hexagonalnej. Jeżeli czytałeś wcześniejsze artykuły to zapewne już wiesz, że użycie konkretnej architektury zależy od tego czego chce biznes. W przypadku architektury hexagonalnej dobrym wyborem jej zastosowania wydają się być projekty o zmiennej i złożonej logice biznesowej. Natomiast zastosowanie jej w CRUD-ach będzie zdecydowanie przesadą i przerostem formy nad treścią. Zamiast uprościć zrozumienie, możesz je tylko niepotrzebnie skomplikować.

Źródła:

• Hexagonal architecture
• Hexagonal Architecture with Java and Spring
• Hexagonal Architecture: three principles and an implementation example
• Build Maintainable Systems With Hexagonal Architecture
• Hexagonal Architecture by example – a hands-on introduction
• ITT 2018 – Jakub Nabrdalik – Hexagonal Architecture in practice

Za tydzień

Moja lista todo robi się coraz dłuższa… jednak zanim zacznę ją czyścić (może powinienem pisać 2 artykuły tygodniowo) chciałbym dokończyć serię o architekturach aplikacyjnych. Dlatego też za tydzień opiszemy popularną architekturę mikroserwisów.

Artykuł Architektura Hexagonalna [Cebula/Porty i Adaptery] 🔥👍 pochodzi z serwisu bdabek.pl.

Cześć 

Architektura typu mikrojądro to już trzeci wpis z mini-serii blogów o architekturach aplikacyjnych. W poprzednich wpisach mogłeś przeczytać o architekturze warstwowej i architekturze sterowanej zdarzeniami.

W dzisiejszym artykule:

• Czym jest architektura mikrojądra?
• Przykłady
• Wady i zalety architektury

Czym jest architektura mikrojądra?

Architektura mikrojądra lub inaczej architektura wtyczek stosowana jest najczęściej kiedy oprogramowanie musi być w stanie dostosować się do zmieniających się wymagań systemowych.

Mikrojądro składa się z dwóch elementów: jądra (rdzeń systemu) oraz wtyczek (pluginów). Rdzeń w najprostszych słowach jest jakimś podstawowym elementem (czasami podstawową funkcjonalnością) systemu. Zawiera on minimalną ilość kodu jaki jest potrzebny do uruchomienia systemu. Reszta leży na barkach wtyczek. Każda wtyczka to całkowicie oddzielna logika biznesowa. Z założenia, wtyczki nie powinny wiedzieć o sobie nawzajem (nie zawsze się tak dzieje) i być całkowicie niezależne. Każda z wtyczek dostarcza konkretną funkcjonalność biznesową do systemu. Innymi słowy – rozszerza go.

Jądro musi w jakiś sposób wiedzieć jakie wtyczki są dostępne oraz jak się do nich dostać. Do tego celu służy rejestr. Zawiera on informacje o wtyczkach oraz ich kontrakt. Kontrakt to zasadniczo dane wejściowe i wyjściowe – pozwala on na wymianę danych pomiędzy rdzeniem i wtyczką. Nie zawsze będzie tak, że wtyczka domyślnie wspiera zdefiniowany kontrakt. Stosuje się wtedy wzorzec projektowy adapter, który odpowiednio zmapuje funkcjonalność.

Mikrojądro można traktować trochę jak wzorzec metody szablonowej. Mówi ono co ma się zadziać i w jakiej kolejności, natomiast jak to się zadzieje jest już zależne od użytych wtyczek.

Przykłady

Najlepszymi przykładami (do wytłumaczenia) są: IDE, edytory tekstu i przeglądarki.

IDE. Zapewnia nam podstawową funkcjonalność – widzimy strukturę projektu, możemy pisać kod i go uruchamiać. IntelliJ wspiera różne języki JVM’owe do kompilacji oraz uruchamiania. Jest to właśnie element wtyczki. Jądrem systemu jest kompilacja i uruchomienie, natomiast wtyczką konkretny język. Ich kontraktem wyjściowym jest zapewne byte code. Rejestrem w tym przypadku będzie język jaki wybraliśmy przy tworzeniu projektu.

Przeglądarki. Jądrem systemu w tym przypadku jest przeglądanie witryn internetowych. A wtyczki? Istenieje duże prawdopodobieństwo, że sam posiadasz zainstalowanych kilka(naście) różnych wtyczek. Wszystko to rozszerza główną funkcjonalność – przeglądanie witryn internetowych – uzupełniając ją o dodatkową logikę.

Spring Boot. Nie jestem w 100% pewny czy jest to trafiony przykład ale powiem jak ja to widzę i rozumiem. Spring przy starcie aplikacji czyta wiele plików konfiguracyjnych, rejestruje bean’y, wykonuje prace zarejestrowane w post processorach i innych. Jeżeli spojrzymy na to z punktu widzenia mikrojądra to można odebrać wrażenie, że jądrem w tym przypadku jest start aplikacji. Wtyczki są to bean’y, post processory i inne udogodnienia, które się dzieją na starcie. Rejestrem może być plik konfiguracyjny, XML lub adnotacja. Kontraktem jest natomiast interfejs.

Nie jestem w 100% pewny czy ostatni przykład jest dobry. Jeżeli znasz jakieś przykłady z życia wzięte (czytaj framework) to podziel się w komentarzu

Wady i zalety architektury

Zalety:

• Testowalność – osobne, niezależne wtyczki, które można przetestować w izolacji. Samo jądro również jest minimalną częścią systemu, które nie powinno być uciążliwe w testowaniu (+ można wykorzystać mockowanie).
• Konfigurowalność – można na różne sposoby skonfigurować ten sam proces, np. kompilacja projektu przy użyciy Javy, Kotlina, Groovy’ego czy Scali.
• Rozszerzalność – łatwo dodać nową wtyczkę, która rozszerzy funkcjonalność systemu. Przykład: powstaje nowy język JVM’owy – większość dobrych IDE (patrz IntelliJ) nie będzie miała problemu aby go wesprzeć.

Wady:

• Skalowalność – mikrojądro pracuje w obrębie jednego modułu. Dokładając kolejne wtyczki może to być wąskie gardło tej architektury w kontekście wydajności.
• Złożoność – jest to skomplikowany styl architektoniczny. Mamy dużo elementów do ogarnięcia – rejestr, kontrakty, konfiguracja wtyczek – to wszystko sprowadza się do wysokiego progu wejścia.

Podsumowanie

Architektura mikrojądra z założenia jest prosta. Nie jest ona natomiast łatwa. Przy większych projektach (których produkt ma żyć długo) – a zazwyczaj właśnie takie projekty powinny z niej korzystać  – jest ona ciężka do ogarnięcia dla nowej osoby. Jej główną zaletą jest elastyczność i to ten driver architektoniczny powinien przemawiać za wyborem tej architektury. Kluczowe jest aby przed jakąkolwiek implementacją mieć wizję i plan – po prostu trzeba wykonać dokładną analizę projektu.

W przypadku aplikacji opartych na produktach (IDE, edytory tekstu, przeglądarki, …) architektura mikrojądra wydaje się być świetnym kandydatem. Pozwala ona na udostępnianie dodatkowych funkcji użytkownikowi w zależności od jego preferencji. Dodatkowo, dzięki kontraktom nie musisz sam wytwarzać każdej nowej wtyczki a zamiast tego użyć community zbudowanego wokół produktu :).

Źródła:

• Software Architecture Patterns (Mark Richards) – Chapter 3. Microkernel Architecture
• What is a microkernel architecture, and is it right for you?
• Software Architecture Patterns — Microkernel Architecture
• Dynamic component binding made easier – An easy to use Microkernel to help reap Contract-First-Design benefits in .NET programs

Za tydzień

Kontynuujemy serię o archiekturze! Kolejna będzie architektura Hexagonalna.

Artykuł Architektura Mikrojądra 🥥🥝 pochodzi z serwisu bdabek.pl.

Cześć 

O zdarzeniach mówi się sporo. Ostatnimi latami są one popularyzowane a czasami co nieco przekoloryzowane. W architekturze jest tak, że nie ma jednego złotego grala na rozwiązanie wszystkich problemów. Z pewnością architektura sterowana zdarzeniami sprwadza się przy pewnych problemach natomiast wpychana na siłę w każdy projekt jest drogą do porażki. Jako odpowiedzialni developerzy nie chcemy uprawiać CV-Driven-Development, zamiast tego świadomie wybieramy to co potrzebne.

Chcę żebyś po przeczytaniu tego artykułu znał zalety i wady podjętej decyzji, zobaczył realny przykład użycia architektury (tak żebyś mógł to sobie lepiej zobrazować) i mógł podjąć świadomą decyzję o wyborze architektury.

W dzisiejszym artykule:

• Czym jest architektura sterowana zdarzeniami
• Topologia: Mediator vs Broker
• Wady i zalety architektury

Czym jest architektura sterowana zdarzeniami

Aby odpowiedzieć na pytanie czym w ogóle jest architektura sterowana zdarzeniami (Event-Driven Architecture / EDA) należy zdefiniować pojęcie zdarzenia.

Zdarzenie jest zmianą stanu aplikacji, która już nastąpiła. Zdarzenie jest niezmienne i nie możemy go cofnąć. Zdarzenia mogą być rozumiane jako wiadomości przesyłane pomiędzy różnymi modułami systemu.

W praktyce zdarzenia są wyzwalaczami (triggerami) pewnych zachowań w systemie. Samo zdarzenie nie jest świadome kto z niego korzysta. Zdarzenia są tworzone przez tzw. producentów (normalny serwis tylko produkujący zdarzenia) i przesyłane są do szyny zdarzeń (jakiś message broker, np. RabbitMQ czy Apache Kafka). Szyna odpowiednio filtruje i wypuszcza zdarzenia dalej do konsumentów. Konsumentem może być każdy. Może to być na przykład jakiś kolejny serwis będący producentem dla innego zdarzenia.

Architektura oparta na zdarzeniach posiada niski coupling (jest luźno powiązana), ponieważ producenci zdarzeń nie są świadomi którzy konsumenci ich nasłuchują (nawet nie wiedzą czy ktokolwiek nasłuchuje), a samo zdarzenie nie wie, jakie są konsekwencje jego wystąpienia. Jest to z pewnością jedna z dużych zalet bo w praktyce oznacza to, że możemy dołączać nowych producentów i konsumentów w optymalny sposób (nie jest to tak trywialne jak by się mogło wydawać).

A więc w prostych słowach jak można zdefiniować EDA? Jest to architektura reagująca na zdarzenia w systemie. Zdarzenia mogą być wewnętrzne (np. dodano produkt do zamówienia) lub zewnętrzne (np. pomiary z czujnika parkowania w samochodzie). Zdarzenia są tworzone przez producentów a ich odbiorcami są konsumenci. Każde zdarzenie przechodzi przez szynę zdarzeń (niektórzy nazywają to również kanałem zdarzeń – ang. event channel), ta natomiast jest implementowana głównie przy użyciu topologii mediatora lub brokera.

Topologia: Mediator vs Broker

Topologia mediatora jest używana kiedy zdarzenia składają się z kilku kroków i potrzebują pewnego rodzaju koordynacji do prawidłowego przetworzenia. Najlepiej przedstawić to na przykładzie.

Kupujesz bilet do kina. Wybrałeś seans, miejsce, przekąski i dokonujesz zapłaty. System w tym momencie wysyła na kolejkę zdarzenie: Kupiono bilet (miejsce: 3A, seans: Straszny film, sala: 6, czasRozpoczęcia: 17:00, itp.). Zdarzenie to jest wysyłane na kolejkę, która przekazuje je do mediatora (szyna koordynująca). Mediator następnie wysyła ’nowe’ zdarzenia na poszczególne kanały. W naszym przypadku będą to trzy nowe zdarzenia uruchomione asynchronicznie: Zarezerwuj bilet, Zarezerwuj miejsce na sali oraz Zaktualizuj liczbę odwiedzających. Kiedy zdarzenia się powiodą, mediator wysyła jeszcze jedno zdarzenie: Wyślij powiadomienie o pomyślnej rezerwacji.

Każde ze zdarzeń produkowanych przez mediatora jest przetwarzana przez tzw. event processor. Warto zauważyć, że takich procesorów dla konkretnego zdarzenia możemy podpiąć wiele. Jest to duża zaleta dla systemów, które potrzebują wysokiej dostępności.

Topologię brokera stosuje się natomiast kiedy produkowane zdarzenie nie jest zbyt skomplikowane i nie wymaga orkiestracji. Tak właściwie to przykład z góry nawet lepiej komponuje się właśnie do topologi brokera.

Wysyłane jest zdarzenie Kupiono bilet (miejsce: 3A, seans: Straszny film, sala: 6, czasRozpoczęcia: 17:00, itp.), które trafia na kanał Rezerwacji. Kanał ten produkuje nowe zdarzenie  Zarezerwuj bilet. Na zdarzenie rezerwacji biletu nasłuchują dwa kolejne kanały rezerwacja miejsca (Zarezerwuj miejsce na sali) oraz aktualizacja odwiedzających (Zaktualizuj liczbę odwiedzających). Rezerwacja miejsca wysyła nowe zdarzenie Zarezerwuj miejsce na sali które trafia na kanał powiadomień (Wyślij powiadomienie o pomyślnej rezerwacji).

Jeżeli dalej masz problem ze zrozumieniem bo kiepowato to wytłumaczyłem (to jest prawdopodobne) to zajrzyj do tej książki (dostęp online dzięki oreilly).

Wady i zalety architektury

Jak już wiesz (lub właśnie się dowiesz) każda architektura rozwiązuje problemy z pewnych kategorii. Kategorie te są często definiowane przez drivery architektoniczne (np. szybkość developmentu, niezawodność platformy, bezpieczeństwo, itp.). Nie ma rozwiązania uniwersalnego i tak samo jest z architekturą sterowaną zdarzeniami.

Zaletami architektury sterowanej zdarzeniami są:

• Skalowalność i niezawodność – serwisy są świadome istnienia tylko szyny zdarzeń. Oznacza to, że możemy dodawać wiele serwisów i w przypadku awarii jednego z nich, inne będą działać dalej.
• Wydajność – operację mogą być wykonywane asynchronicznie.
• Zwinność – dzięki temu, że komponenty mają luźny coupling można dodawać nowe lub usuwać stare bez większych obaw, że coś się zepsuje.

Natomiast do wad należą:

• Development – należy rozumieć i umieć programować asynchroniczne.
• Testowalność – wymaga specjalnych narzędzi do generowania zdarzeń oraz kontraktów pomiędzy różnymi serwisami. Dodatkowo, natura architektury (asynchroniczność) jest także problematyczna, np. nie zawsze dostajemy zdarzenia w tej samej kolejności.

Podsumowanie

Przy użyciu architektury sterowanej zdarzeniami system może reagować na zmiany w czasie rzeczywistym. Analizując zdarzenia w systemie (które są dostarczane na bieżąco) biznes jest w stanie podejmować decyzje szybciej i dokładniej. Jest to napewno jeden z driverów architektonicznych jakie należy brać pod uwagę wybierając architekturę systemu.

EDA jest skomplikowanym wzorcem architektonicznym dlatego istnieje kilka wzorców projektowych pozwalających osiągnąć taką architekturę, są to m.in: Notification Pattern, Event-Carried State Transfer (ECST),  Event Sourcing (ES), CQRS. Więcej na temat możesz przeczytaj u Martina Fowlera lub w tym artykule na medium.

Innym plusem EDA jest to, że pozwala na dostarczanie featerów bez modyfikacji i zajmowania czasu zespołowi, który jest odpowiedzialny za usługę produkującą zdarzenia. Wystarczy raz coś napisać i później wysyłać zdarzenia. Jeżeli ktoś będzie chciał zareagować na to zdarzenie to po prostu dodaje akcję (konsumenta). Nie tracimy wtedy czasu na komunikację i dostosowywanie konkretnych usług – po prostu mamy wystawiony pewien kontrakt i jak ktoś chce się dostosować to to robi.

Źródła:

• GOTO 2017 • The Many Meanings of Event-Driven Architecture • Martin Fowler
• Software Architecture Patterns (Mark Richards) – Chapter 2. Event-Driven Architecture
• EVENT DRIVEN ARCHITECTURE
• The importance of event-driven architecture in the digital world

Za tydzień

Chcę napisać coś osobistego – całkowicie niezwiązanego z programowaniem. Dawno takiego wpisu nie miałem a czuję że tego potrzebuję. Wpis będzie poświęcony ustawianiu celów i ich wartości w życiu.

Artykuł Architektura Sterowana Zdarzeniami ✨ pochodzi z serwisu bdabek.pl.

Cześć 

Każdy z nas używał architektury warstwowej, czy to przechodząć przez tutorial w sieci czy implementując aplikacje komercyjne lub niekomercyjne. Jest ona na tyle popularna, że aż bardzo często użyta tam gdzie wcale nie sprawdza się najlepiej. Niemniej jednak, nie chcę żeby ten artykuł szedł w stronę, że architektura warstwowa jest złem. Absolutnie nie! Będąc świadomym programistą powinniśmy umieć dobrać odpowiednią architekturę do problemu jaki jest przed nami (i naszym zespołem!).

W dzisiejszym artykule:

• Czym jest architektura warstwowa?
• Rzeczywistość architektury
• Wady i zalety architektury warstwowej

Czym jest architektura warstwowa?

Na początku musimy zacząć w ogóle od wyjaśnienia czym jest architektura warstwowa. Jeżeli jeteś programistą (a zakładam, że jesteś) to na 100% już się z nią spotkałeś. W teorii zakłada ona podział strukturalny projektu na kilka warstw. W wielu przypadkach będą to głównie 3 warstwy: prezentacji, logiki oraz persystencji. Aczkolwiek nie ma problemu żeby warstw było 5 lub 2.

Żebyś mógł to sobie lepiej zobrazować to te 3 warstwy przyrównam do typowej aplikacji pisanej w springu:

• • warstwa prezentacji = kontrolery,
  • warstwa logiki = serwisy,
  • warstwa persystencji = repozytoria.

Architektura warstwowa ma dwa fundamentalne założenia:

1. 1. każda warstwa jest odseparowana od siebie – wykonuje tylko tą pracę do której została stworzona.
   2. komunikacja jest kierowana od góry do dołu (warstwa prezentacji wykorzystuję logikę a ta persystencję)

Pomimo, że zasada numer dwa, która mówi iż komunikacja jest kierowana od góry do dołu może sugerować wprowadzenie zależności pomiędzy warstwami to takie myślenie nie jest poprawne. Warstwy są od siebie niezależne. Są one tylko powiązane (wywołanie warstwy niższej przez warstwę wyższą) ale nie należy mylić tego z zależnością. W praktyce oznacza to, że implementacje warstw mogą być łatwo wymienne. Jeżeli chcemy zamienić persystencję z Hiberneta na MyBatis to nie powinno to wpływać jakkolwiek na inne warstwy.

Możemy sobie wyobrazić sytuacje kiedy piszemy bardzo prostego CRUD’a. Nie posiada on logiki biznesowej (lub posiada jej bardzo mało). Czy powinniśmy w takim razie tworzyć warstwę logiki? Są dwie szkoły. Jedna, bardziej restrykcyjna mówiąca, że obligatoryjnie tworzymy wszystkie warstwy wymagane w projekcie a przepływ w naszej aplikacji jest zawsze taki sam. Przy takim podejściu mówi się, że warstwy są zamknięte. Natomiast druga szkoła pozwala na rozluźnienie, warstwy mogą być otwarte. Które podejście jest lepsze? Oba są prawidłowe. W architekturze jest dużo abstrakcji i stety, niestety wyraz to zależy może być używany bardzo często.

Dlaczego to zależy? Zobacz, moglibyśmy zezwolić na wywołanie warstwy persystencji bezpośrednio przez warstwę prezentacji. Chyba byśmy tym nie zgrzeszyli? Natomiast pozwalając sobie na takie manewry rozluźniamy granice naszej aplikacji. Nie tylko my pozwalamy na rozluźnienie ale jest jeszcze cały zespół. Kiedy komunikacja w zespole nie jest na najlepszym poziomie lub nad modułami pracuje kilka zespołów (jest to uciążliwe zwłaszcza przy dużych projektach) nasza architektura staje się krucha. Nie kontrolujemy, które warstwy mogą być otwarte a które nie. Kod staje się cięższy w testowaniu i utrzymywaniu a zależności między warstwami narastają.

Rzeczywistość architektury

Problem z architekturą warstwową jest taki, że w rzeczywistości wygląda ona nieco inaczej. Mamy moduły naszej aplikacji i przepływ od góry do dołu. Dopóki aplikacja nie jest duża, udaje nam się utrzymać prawidłowy przepływ. Problemem jest moment w którym aplikacja masowo przyrasta – zwiększa się ilość zespołów nad nią pracujących, powstają nowe, szybkie featuer’y. Biznes chce widzieć efekty jak najszybciej, tworzy presję na developerach a to zazwyczaj prowadzi do tego, że nie myślimy o designie aplikacji jako całości. Skupiamy się wyłącznie na tym co chemy dostarczyć w tym momencie – jak najszybciej. Końcowo doprowadza to do architektury warstwowej, która już nie wygląda tak pięknie jak była przedstawiana w tutorialach.

Istnieje rozwiązanie tego problemu. Wymaga ono jednak zastanowienia się do czego będzie nam służyć dany feature. Czy nie powinien być on osadzony w osobnym module? Dodatkowy podział aplikacji na moduły – gdzie każdy z modułów ma swoją implementację architektury jest złotym środkiem. Wiem, że znajdą się przeciwnicy tego rozwiązania mówiąc, że robi nam się wtedy misz-masz różnych styli architektonicznych. Macie rację :). Trzeba to dopasować odpowiednio do umiejętności zespołu. Co na przykład stoi na przeszkodzie żeby jeden moduł wykorzystywał architekturę trójwarstwową a drugi dwuwarstwową? Moim zdaniem nic. Należy tylko umieć odpowiednio zdiagnozować problem jaki rozwiązujemy. Sprawdzić, czy robimy CRUD’a czy coś co wymaga bardziej złożonej logiki. No i jeszcze bardzo ważne – trzymać się założeń jakie poczyniliśmy.

(Ot takie moje dumanie..)

Wady i zalety architektury warstwowej

Zalety:

• Powszchechna. Większość ludzi ją zna i nie będzie miało problemu żeby odnaleźć się w projekcie.
• Zmniejsza złożoność – warstwy niskopoziomowe możemy zastąpić warstwami wyższymi. Coś a’la fasada.
• Separuje odpowiedzialność – pozwala na wymianę implementacji poszczególnej warstwy bez wpływu na inną

Wady:

• Zmiany wymagane w wielu warstwach. Zmieniając warstwę widoku prawdopodobnie będziemy musieli również dotknąć warstwy logiki i persystencji.
• Ukryty cel – patrząc na strukturę projektu nie jesteśmy w stanie powiedzieć jaki problem rozwiązuje. Dopiero spojrzenie w klasy znajdujące się w pakietach coś nam zaczyna podpowiadać.

W wielu wpisach na mediach jako zaletę tej architektury wymienia się również testowalność. Nie zgadzam się z tym stwierdzeniem w 100% ale też nie neguję. Owszem, możemy testować wyłącznie jedną warstwę, tylko problem jaki widzę jest taki, że kończy się to na mockowaniu 99 obiektów i testowaniu jednej malutkiej funkcjonalności. To jest złe ale nie jest tragiczne. Tragedia przychodzi kiedy w mockowanych API powstają zmiany i nasz test dalej przechodzi pomimo, że już nie powinien. W taki sposób powstają testy, które zadawalają biznes pokryciem kodu ale w rzeczywistości są do wyrzucenia… to jest temat na inny wpis.

Podsumowanie

Architektura warstwowa to dobre rozwiązanie w wielu przypadkach. Pozwala na szybki rozwój aplikacji w początkowych fazach a dodatkowo dzięki jej zastosowaniu wiemy, że każdy nowy członek zespołu wdroży się w miarę szybko. Jeżeli tworzymy aplikację, która nie jest duża to moim zdaniem architektura warstwowa może spełnić swoje zadanie doskonale.

Czasami mamy inne potrzebny a realia są niestety takie, że większość programistów nie zna stylów architektury. To powoduje, że bez edukacji zespołu nie jesteśmy w stanie wdrożyć czegoś bardziej odpowiedniego. Dlatego ważne jest aby szerzyć wiedzę i uczyć się nowych rzeczy – również o architekturze

Źródła:

• Layered Architecture Is Good
• Software Architecture Patterns — Layered Architecture
• Software Architecture Patterns (Mark Richards) – Chapter 1. Layered Architecture
• Patterns of Enterprise Application Architecture (Martin Fowler) – Service Layer

Za tydzień

Kolejny wzorzec architektoniczny: Event-Driven Architecture. Myślę, że przelecimy przez wszystkie wzorce z książki Mark’a Richards’a. Jest to edukujące i ciekawe.

Artykuł Architektura warstwowa. Zło czy dobro? 🤔 pochodzi z serwisu bdabek.pl.

Cześć 

Na przełomie czasów została rozwiązana już masa problemów z wykorzystaniem przeróżnych rozwiązań – jedne się sprawdziły, inne niekoniecznie. Problemy z jakimi stawiamy się jako programiści w teraźniejszości prawdopodobnie zostały już przepracowane przez kogoś innego. Myślę, że w 90% to co wyróżnia nasze programy to biznes i koncepcja za nim stojąca. Jednak jeżeli się zastanowimy to może się okazać, że każdy z tych biznesów ma coś wspólnego. Większość z rozwiązywanych problemów u swoich podstaw jest podobna… Taka mysł na start, która z tym artykułem ma trochę wspólnego ale na ten temat można śmiało poświęcić cały osobny wpis.

A teraz nie przedłużając dalej. W dzisiejszym artykule:

• Czym jest model anemiczny?
• Czym jest model bogaty?
• Co jest lepsze?

Czym jest model anemiczny?

Model anemiczny to nic innego jak model posiadający dane (pola/atrybuty) oraz połączenia do innych modeli (referencje). Taki model będzie też posiadał zestaw getterów i setterów. Logika biznesowa takiego modelu jest używana przez różnego rodzaju serwisy, utilsy i inne manager’y. To one definiują zachowania i reguły.

Będąc w projektach komercyjnych od ponad 2 lat spotykałem się głównie z takim podejściem. Mogę przez to wnioskować, że jest ono nadużywane. Dlaczego tak się dzieje? Do głowy przychodzą mi trzy powody.

• Jeden – wiele tutoriali zostało napisanych właśnie w taki sposób. Twórcy popularnych frameworków sugerują nam takie rozwiązania, poprzez przedstawianie nam poradników jak używać ich frameworków w szybki sposób.
• Dwa – nie zastanawiamy się nad tym do czego dany model jest potrzebny, jaki problem ma rozwiązywać. PO mówi: feature będzie służył do rezerwacji hoteli, tutaj masz schemat bazy, wiesz jak to będzie wyglądać i działajmy. I później szybko klepiemy schemat bazy 1:1 z obiektami. A po miesiącu dochodzą nowe funkcjonalności, które – uwaga – opędzlowujemy przez nowe serwisy. I tak do momentu aż projekt umiera i piszemy go od nowa. Brzmi znajomo?
• Trzy – jest prosty w użyciu. Super prezentacja z Confitury z 2013 roku omawiająca ten problem : Encja na twarz i pchasz.
• Cztery – nie mamy umiejętności. Powód jeden i dwa bardzo temu sprzyjają. Nie mamy czasu się nauczyć programować inaczej. Jeżeli obracamy się w środowisku, gdzie wszyscy pracują w taki sam sposób to być może nigdy nie będziemy mieli tego czasu na naukę. Smutna prawda.

W roku 2003 Martin Fowler zdefiniował model anemiczny jako anty wzorzec. Zwraca on szczególną uwagę na brak spójności takiego podejścia z programowaniem obiektowym a nawet zarzuca, że jest to proceduralny styl projektowania.

The anemic domain model is really just a procedural style design…

Jedną z fundamentalnych podstaw programowania obiektowego jest enkapsulacja. Co to oznacza? Nasze dane powinny być ukrywane. A my co robimy?

public class User {
   private String name;
   private String idNum;

   public String getName() {
      return name;
   }

   public String getIdNum() {
      return idNum;
   }

   public void setName(String newName) {
      name = newName;
   }

   public void setIdNum(String newId) {
      idNum = newId;
   }
}

Na początku naszych 'karier’ wmawia się nam, że enkapsulacja to ukrywanie pól i używanie akcesorów do nich. Błąd! Enkapsulacja polega na ukrywaniu danych! Tylko jeżeli ukryjesz dane modelu i nie zdefiniujesz w nim zachowań to w jaki sposób chcesz zmieniać jego stan?

Czym jest model bogaty?

Model bogaty, w przeciwieństwie do anemicznego, poza samymi danymi definiuje również logikę domenową. Dane i zachowania są spójne. Zachowania są częścią i rezultatem modelu. Logika jest odpowiedzialna za inicjalizację obiektów, walidację i operowanie na modelu.

Dzięki takiemu podejściu klient danej domeny nie musi się martwić którego serwisu musi użyć. Albo czy zmieniając dane w jednym serwisie nie zepsuje logiki w innym. Wszystkie zmiany danych związane z obiektem są zdefiniowane właśnie w nim. Pozwala to kontrolować stan obiektu, dzięki czemu unikamy stanu niespójności.

Nie oznacza to, że całkowicie pozbywamy się serwisów. One nadal są – tylko służą nam do innych celów, np. wysyłanie maili. Cytat z książki DDD Erica Evans’a:

This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

Nie będę w tym artykule się zagłębiał w podejście DDD, czym są agregaty, value objecty, itd. Przedstawię Ci natomiast prosty model subskrypcji, który jest implementacją modelu bogatego. Zachowania są definiowane razem z danymi i są ściśle powiązane z obiektem.

public class Subscription {
    
    private Status status = Activated;
    private final Clock clock;
    private final SubscriptionId subscriptionId;
    private final Enrollment enrollment;
    
    public static Subscription subscription(int maxSubscribers, int maxOnWaitingList) {
        return new Subscription(systemDefaultZone(), Enrollment.emptyWithCapacities(maxSubscribers, maxOnWaitingList), SubscriptionId.newOne());
    }

    public static Subscription subscription(int maxSubscribers, int maxOnWaitingList, SubscriptionId subscriptionId) {
        return new Subscription(systemDefaultZone(), Enrollment.emptyWithCapacities(maxSubscribers, maxOnWaitingList), subscriptionId);
    }

    Subscription(Clock clock, Enrollment enrollment, SubscriptionId subscriptionId) {
        this.clock = clock;
        this.enrollment = enrollment;
        this.subscriptionId = subscriptionId;
    }

    enum Status {
        Activated, Disabled
    }

    Result activate() {
        this.status = Activated;
        return success(new SubscriptionActivated(subscriptionId, Instant.now(clock)));
    }

    Result disable() {
        this.status = Disabled;
        return Result.success(new SubscriptionDisabled(subscriptionId, Instant.now(clock)));
    }
}

Zero niepotrzebnych udostępnień danych. Wszystko wykonywane jest przez zdefiniowane zachowania. W tym przypadku klasa subskrypcji ma dwa bardzo proste zachowanie – może być aktywna lub nieaktywna. I tyle.

Oczywiście nie może być tak kolorowo, musisz zapłacić cenę za to aby Twój design szedł w taką stronę. Ceną jest czas i umiejętność komunikacji. My (developerzy) dostarczamy rozwiązania biznesom, które mają na tym zarobić. Oni wiedzą w jaki sposób ma działać ich biznes (ich domena). A my? No już nie koniecznie. Naszym zadaniem jest zdobyć tą wiedzę. Dopytywać, dociekać i dopiero wtedy projektować. Na youtubie możesz obejrzeć świetną prezentację Sławka Sobótki, która pokazuje taki proces event stormingu.

Co jest lepsze?

Trochę 'clickbaitowo’ rzuciłem hasło co jest lepsze. Oczywiście to zależy.

Jeżeli piszesz CRUD’a, gdzie nie ma żadnej walidacji, żadnej logiki lub jest ale jest jej mało, to nie ma co się rozwodzić. Używasz modelu anemicznego i wykorzystujesz powiedzenie encja na twarz i pchasz.

Natomiast kiedy widzisz, że logika w domenie w jakiej pracujesz staje się skomplikowana, użyj modelu bogatego. Co to znaczy skomplikowana? Powstają nowe walidacje, zmieniają się stare reguły, dochodzą nowe – generalnie – jest dużo zmienności.

Podsumowanie

Model anemiczny możesz tłumaczyć jako:

• posiadający wyłącznie dane, nie posiadający prawie żadnej logiki.
• serwisy zarządzają atrubytami takiego modelu poprzez akcesory i to one definiują logikę aplikacji
• dane są oddzielone od reguł (zarządzają nimi serwisy)

Model bogaty natomiast:

• logika jest zaimplementowana w obiektach modeli
• serwisy stanowią jedynie cienką wartstwę wspomagającą serwisy trzecie (np. zapis do bazy, koordynacja zadań)
• dane są dostępne tylko przez reguły (reguły to zachowania domenowe)

Źródła:

• Domain-Driven Design vs. anemic model. How do they differ?
• AnemicDomainModel
• Anaemic Domain Model vs. Rich Domain Model
• The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design
• Anemic Domain Model vs Rich Domain Model with Examples

Za tydzień

Porozmawiamy o czasie w Javie. Co używać, jak używać i jakie są konekwencje.

Artykuł Anemic Domain Model vs Rich Domain Model – Co to❔❓ pochodzi z serwisu bdabek.pl.