DEV Community: Kamil Kozak

Modularny monolit

Kamil Kozak — Wed, 26 Oct 2022 20:41:35 +0000

Można spotkać się z opinią, że Architektura Monolityczna jest równoznaczna z trudnym do utrzymania, niechlujnym kodem. Choć monolit wcale nie wyklucza przejrzystej architektury nie trudno doprowadzić do stanu gdy kod przypomina wielką kule błota (big ball of mud). Winę za taki stan rzeczy ponoszą między innymi tutoriale i dokumentacje frameworków, które skupiają się na szczegółach technicznych z pominięciem architektury. Nie trudno o przykłady kodu gdzie kontrolery są umieszczanie z kontrolerami, a modele z modelami. W dużej aplikacji doprowadzi to prędzej czy później do problemów z architekturą.

Śledząc konferencje programistyczne w ostatnich latach można zauważyć, że Mikroserwisy zyskały na popularności. Jest to spowodowane prawdopodobnie tym, że zaczęło ich używać wiele firm pokroju Netflixa. Firmy te mają specjalne wymagania, których Architektura Monolityczna nie jest w stanie spełnić. Mikroserwisy zaczęły być reklamowane jako Silver Bullet, który rozwiązuje wszystkie problemy rozwoju oprogramowania.

Architektura Mikroserwisowa to właściwy wybór w wielu przypadkach użycia, ale jak każda inna Architektura Oprogramowania, ma również słabe punkty. Architektura Monolityczna również ma miejsce w nowoczesnym tworzeniu oprogramowania. Każda architektura oprogramowania ma swój własny zestaw zalet i wad, a inne rozwiązanie będzie miało sens dla aplikacji zależnie od fazy jej rozwoju.

Modularyzacja

Wikipedia o Aplikacji Monolitycznej:

Inżynieria oprogramowania opisuje aplikację monolityczną jako zaprojektowaną bez modułowości (podziału na moduły). Ogólnie rzecz biorąc, modułowość jest pożądana, ponieważ umożliwia ponowne wykorzystanie części logiki aplikacji, a także ułatwia konserwację, umożliwiając naprawę lub wymianę części aplikacji bez konieczności wymiany hurtowej.

dalej

Modułowość jest osiągana w różnym stopniu przez różne podejścia do modularyzacji.

Można spotkać się też z definicją:

Monolit to system, który ma dokładnie jedną jednostkę wdrożeniową.

Zła reputacja Monolitów wynika z tego, że nie poddaje się ich odpowiedniej modularyzacji. Granice między różnymi domenami nie są przestrzegane co z czasem doprowadzi do wysokiego couplingu, który zastopuje rozwój i utrudni utrzymanie. Modularyzacja pozwoli uzyskać zalety zarówno monolitów, jak i mikroserwisów bez zwiększania liczby jednostek wdrożeniowych.

Aby osiągnąć modularność, a co za tym idzie architekturę modułową trzeba podzielić system na mniejsze kawałki czyli moduły, które są niezależne i wymienne, a każdy moduł musi mieć zdefiniowany interfejs i zaimplementować wszystko, co jest niezbędne do zapewnienia funkcjonalności biznesowej, którą opisuje interfejs.

Niezależność

Moduł nigdy nie jest całkowicie niezależny, zawsze zależy od czegoś innego. Jednak zależności powinny być ograniczone do minimum zgodnie z zasadami: Low Coupling, High Cohesion. Aby określić, jak niezależny i wymienny jest moduł, musimy przyjrzeć się trzem czynnikom: liczbie zależności, sile tych zależności oraz stabilności modułów, od których zależy.

Funkcjonalność biznesowa

W systemie typu "big ball of mud" spotkamy się z grupowaniem kodu na moduły techniczne - moduł dostępu do bazy danych, moduł systemu kolejek itd czyli plastry poziome (horizontal slices). Zmiana techniczna spowoduje zmianę w jednym module, ale zmiana biznesowa dotknie ich wszystkich. Jednak zmiany w systemie częściej dotyczą biznesu i z tego powodu moduły powinny być biznesowe - plastry pionowe (vertical slices). W ten sposób częste zmiany dotyczą tylko jednego modułu – staje się on bardziej samodzielny, autonomiczny i sam jest w stanie zapewnić funkcjonalność.

Interfejs

Moduł powinien mieć dobrze zdefiniowany interfejs – kontrakt, który definiuje, co moduł może zrobić i ukrywa lub hermetyzuje, jak to się robi. Hermetyzacja jest nieodłącznym elementem modułowości. Interfejs służy do komunikacji z innymi modułami. Wszystko, co udostępniamy na zewnątrz, staje się publicznym API modułu. Jeżeli komunikujemy moduły przez zdarzenia to ono również jest kontraktem. Zmiana pola w klasie zdarzenia jest zmianą kontraktu.

Bounded Context

Znakomitą techniką do wyznaczenia modułów jest Bounded Context (Kontekst Ograniczony) czyli centralny wzorzec z Domain Driven Design. W DDD domenę (dziedzinę) oprogramowania odzwierciedlamy w kodzie jako model domeny. Model ten umieszczamy w Kontekście Ograniczonym. Model, aby był skuteczny, musi być zunifikowany – to znaczy być wewnętrznie spójny, aby nie było w nim sprzeczności.

Gdy próbujesz modelować większą domenę, coraz trudniej jest zbudować jeden zunifikowany model. "Klient" w aplikacji do rezerwacji pokoju hotelowego w zależności od kontekstu może oznaczać płatnika, rezerwującego, odbiorcę faktury, gościa pokoju. Tworzenie jednej tabeli i jednego zunifikowanego modelu na wszystkie te konteksty jest przykładem Big Ball of Mud. Zamiast 4 modeli i 4 kontekstów mamy 1 model do 4 kontekstów. Ponieważ każda z tych definicji „Klienta” jest jasna wyłącznie we własnym kontekście, to każda powinna zostać ujęta w osobnym Kontekście Ograniczonym. W każdym kontekście "Klient" będzie opisany innym Językiem Wszechobecnym (Ubiquitous Language). Język Wszechobecny to język wypracowany wokół modelu domeny i używany przez wszyskich członków zespołu.

Kontekst ograniczony nie jest modułem. Zapewnia ramę, w której model ewoluuje. Moduły służą do organizowania elementów modelu, więc Bounded Context obejmuje moduł.

Aby osiągnąć modułowość w najprostszej formie można zacząć od przeniesienia klas z folderów technicznych do folderów nazwanych biznesowo. Wchodzimy w moduł Rezerwacji, a nie moduł kontrolerów czy serwisów. Pierwsze spotkanie z repozytorium kodu mówi nam jakie są funkcjonalności systemu. Kiedy mamy monolit typu spaghetti code to funkcji biznesowych nie widać. Jeżeli mamy wyznaczone moduły zmieniając funkcjonalność wchodzimy w jedno miejsce, zamiast przeszukiwać katalogi z kontrolerami, modelami itd. Rzeczy, które się zmieniają są blisko siebie. Osiągamy High Cohesion i Low Coupling na poziome nie klas, a modułów. Przeciwdziałamy antywzorcowi "Shotgun Surgery" wprowadzając zmiany w module, który tego wymaga, a nie w wielu miejscach jednocześnie w całym systemie.

Drivery Architektoniczne

Lepsze są mikroserwisy czy monolit? Nie da się jednoznacznie odpowiedzieć na pytanie. Przed podjęciem decyzji należy kierować się kontekstem. W pewnych przypadkach nawet Big Ball Of Mud będzie dobrą architekturą gdy system ma powstać szybko i szybko zakończy żywot. Decyzję o wyborze właściwej architektury należy podjąć w oparciu o Drivery Architektoniczne (Architectural Drivers).

Drivery dla Monolitu:

Architektura monolityczna jest łatwa do zbudowania i pozwala wcześniej zaprezentować produkt klientom.
Architektura monolityczna jest bardziej popularna. W związku z tym jest większa ilość dostępnych programistów, którzy są z nią zaznajomieni.
Jeden zestaw infrastruktury. W monolicie wystarczy jeden serwer z bazą danych. Dodatkowa infrastruktura zwiększa również liczbę możliwych punktów awarii, zmniejszając odporność i bezpieczeństwo aplikacji
Architektura monolitu jest mniej złożona niż system rozproszony. Wymaga mniej narzędzi, bibliotek, komponentów itd.
Wdrożenie monolitu jest łatwiejsze.
Monolit ma lepszą wydajność niż Mikroserwisy do momentu pojawienia się potrzeby skalowania.
Jedno repozytorium kodu. Możliwość łatwego wyszukiwania i znajdowania wszystkich funkcji w jednym folderze.
Wszystkie dane mogą znajdować się w jednej bazie danych. Łatwiejsze pobieranie danych z różnych tabel.
Możliwość bezpośredniego wywoływania innych komponentów, zamiast konieczności komunikowania się za pośrednictwem REST API. Nie trzeba się martwić o zarządzanie wersjami API i kompatybilność wsteczną.
Ze względu na mniejszą ilość komponentów niż w mikroserwisach (wiele serwerów, baz danych, połączeń sieciowych, kontenerów, maszyn wirtualnych) kompletna aplikacja jest łatwiejsza do zabezpieczenia .
Łatwiejsze transakcje bazodanowe.
Ze względu na brak połączeń zewnętrznych, całkowite opóźnienie całej aplikacji jest mniejsze.

Drivery dla Mikroserwisów:

Wdrażanie autonomiczne. Mikroserwisy można wdrażać niezależnie.
Wydajniejsze wykorzystanie zasobów przy skalowaniu.
Mniejszy wpływ awarii jednego modułu na resztę systemu niż w Monolicie.
Każdy moduł może być napisany w innym języku programowania w zależności od potrzeb.
Mniejsza ilość wiedzy jaką musi przyswoić programista przed przystąpieniem do pracy. Rozmiar mikroserwisów jest niewielki. Mniej obciąża zdolności poznawcze, a programiści są bardziej produktywni.
Łatwiejszy podział prac między wieloma zespołami oraz zrównoleglenie prac.
Skalowanie granularne czyli skalowanie części aplikacji.
Możliwość użycia bazy danych lepiej dopasowanej do mikroserwisu.
Tak długo, jak zachowany jest zewnętrzny kontrakt, mikroserwis można szybko zastąpić, jak klocki Lego.

Integracja Modułów

Aby dostarczyć system spełniający swoje zadanie potrzebne są sposoby, aby pocięte kawałki systemu mogły się ze sobą komunikować.

Synchroniczna komunikacja

Bezpośrednie wywołanie (Direct Call). Wywołujemy moduł synchronicznie i musimy czekać na odpowiedź. Moduł ma zdefiniowane API czyli kontrakt (interfejs) lub strukturę danych, których możemy używać. Udostępnia tylko to, co jest potrzebne i w ten sposób stan naszego modułu nie jest nadmiernie eksponowany na zewnątrz. Stan systemu jest podzielony na stan modułów. Jeżeli to możliwe powinno się unikać zapisywania w jednej transakcji stanu wielu modułów.

Odpowiednikiem w mikroserwisach jest API RESTowe, na które można stosunkowo łatwo przejść jeżeli Modularny Monolit jest etapem przejściowym w drodze do mikroserwisów.

Coupling jest niższy niż w przypadku Współdzielonej Bazy Danych, ale nadal istnieje.

Asynchroniczna komunikacja

Do komunikacji asynchronicznej służą Zdarzenia (Events). Ten styl integracji ma ogromna zaletę - tworzy minimalne zależności między modułami. Zdarzenia powinny być jak najmniejsze, ponieważ są częścią kontraktu, który udostępnia moduł. Rzucamy Event, a inne moduły się na niego subskrubują.

Wady Zdarzeń:

Eventual Consistency. Ze względu na naturę asynchroniczności stan całego naszego systemu może być Ostatecznie Spójny i należy to brać pod uwagę definiując granice modułów.
Możliwa niewłaściwa kolejność Eventów.

Shared Database

Współdzielona Baza Danych powoduje, że dane w modułach są zawsze spójne, ponieważ są to te same dane. Jeżeli moduł płatności zapisuje dane, moduł rezerwacji może je odczytać natychmiast po zakończeniu transakcji bazodanowej. Rozwiązanie jest mało skomplikowane i wygląda idealnie na pierwszy rzut oka, ale ma szereg problemów.

Mamy wielkie tabele i trudno osiągnąć ujednolicony model danych, który zapewni spełnienie wymagań wszystkich modułów. Drugim problemem jest brak dobrze zdefiniowanego interfejsu ponieważ interfejsem jest tak naprawdę baza danych.

Moduły łączy wspólny stan co oznacza wysokie sprzężenie oraz brak autonomii dla modułu. Nie ma nic łatwiejszego niż jednym zapytaniem pobrać dane do raportu z kilku tabel. Niemniej jednak każda zmiana w strukturze bazy danych może uszkodzić inny moduł.

Z tych przyczyn lepiej wystrzegać się integracji modułów przez Shared Database.

Mapa Kontekstów

Podczas integracji modułów warto wiedzieć o kolejnym koncepcie z Domain Driven Design czyli Mapie Kontekstów. Mapa Kontekstów (Context Map) to dokument, który przedstawia Konteksty Ograniczone i relacje między nimi. Opisuje też relacje między zespołami, które nad nimi pracują.

Jaki styl integracji wybrać? Gdy mówimy o architekturze modułowej, najlepiej mieszać różne style i używać razem Direct Call i Zdarzeń. W zależności od potrzeb jedne moduły mogą komunikować się synchronicznie, inne asynchronicznie.

Architektura Heksagonalna

Jak konkretnie zaimplementować Architekturę Modularnego Monolitu? Nie trzeba wymyślać koła na nowo. W koncepcje omówione do tej pory idealnie wpisuje się Architektura Heksagonalna (lub podobne Onion i Clean Architecture).

System typu Modularny Monolit musi posiadać samodzielne moduły, które zapewniają pełną funkcjonalność biznesową. Architektura Heksagonalna (Porty i Adaptery), doskonale wspiera takie projektowanie zorientowane na domenę. Co więcej, moduły muszą mieć dobrze zdefiniowane interfejsy. Cała komunikacja między modułami powinna odbywać się tylko przez te interfejsy. W Architekturze Heksagonalnej te interfejsy będą Portami. Jak widać ta architektura daje wszystko czego potrzebujemy, aby osiągnąć modułowość dlatego jest naturalnym wyborem.

Moduł będzie zwykle podzielony na warstwy takie jak: Warstwa Aplikacji, Domeny, Infrastruktury. Pomaga to odseparować domenę od reszty kodu. Przy czym część modułów może stanowić tylko proste operacje typu CRUD (Create Read Update Delete). Dlatego stosowanie warstw nie powinno być decyzją globalną - każdy przypadek warto rozpatrzyć osobno.

Architektura heksagonalna (Porty i Adaptery) w Laravelu

Kamil Kozak — Tue, 27 Sep 2022 21:37:43 +0000

Punkt wyjścia do Architektury Heksagonalnej (Hexagonal Architecture) stanowi Architektura Warstwowa. Architektura ta dzieli systemy (aplikacje) na odrębne warstwy. Zgodnie z propozycją Erica Evansa z jego "Blue Book'a" zwykle będzie ich 3 lub 4.

Warstwa Interfejsu Użytkownika
Przedstawia informacje użytkownikowi i interpretuje jego działania.
Warstwa Aplikacji
Organizuje i deleguje obiekty domeny do wykonywania swojej pracy. Nie zawiera logiki związanej z domeną.
Warstwa Domeny
Tu znajdują się koncepcje domeny biznesowej. Encje, które są kombinacją danych i zachowań.
Warstwa infrastruktury
Przechowywanie oraz dostęp do danych. Framework i biblioteki pomocnicze.

Jedną z najważniejszych korzyści stosowania Architektury Warstwowej jest rozdzielenie odpowiedzialności (separation of concerns). Pomaga ona odseparować domenę od pozostałych warstw i należy do wzorców taktycznych z Domain Driven Design. Problemem pozostają wycieki logiki między warstwami. Można łatwo skończyć z logiką biznesową w interfejsie użytkownika lub infrastrukturą w logice biznesowej.

Rozwiązanie tego problemu przedstawił w 2005 roku Alistair Cockburn. Dla niego system składa się tylko z dwóch odrębnych części: wewnętrznej i zewnętrznej. Wnętrze to nasz rdzeń, a na zewnątrz to miejsce, w którym żyje interfejs użytkownika i infrastruktura.

Cockburn doszedł do wniosku, że rdzeń współdziała z interfejsem użytkownika lub bazami danych lub testami automatycznymi w podobny sposób. Dlatego wszystkie te systemy zewnętrzne można oddzielić od rdzenia i komunikować się z nim w sposób niezależny od technologii za pośrednictwem portów i adapterów. Unikając w ten sposób sprzęgania i wycieku logiki między warstwą biznesową, a komponentami zewnętrznymi.

Architektura Heksagonalna jest też nazywana Architekturą Portów i Adapterów (Ports and Adapters). Bardzo podobne architektury dzielące system na warstwy to Clean Architecture - Roberta Martina oraz Onion Architecture - Jeffreya Palermo.

Porty

Port jest bramą do rdzenia aplikacji. Określa on interfejs, który pozwoli zewnętrznym aktorom komunikować się z Rdzeniem, niezależnie od tego, kto lub co zaimplementuje ten interfejs. Porty umożliwiają również Rdzeniowi komunikację z zewnętrznymi systemami lub usługami, takimi jak bazy danych, systemy kolejek, inne aplikacje itp. Porty w kodzie będą reprezentowane jako interfejsy.

Adaptery

Adapter zainicjuje interakcję z Rdzeniem przez Port przy użyciu określonej technologii, na przykład kontroler REST będzie reprezentował adapter, który umożliwia klientowi komunikowanie się z Rdzeniem. Może istnieć wiele adapterów dla każdego portu.

Rdzeń

Alistair do określenia rdzenia używa słowa "Aplikacja". Rdzeń zawiera serwisy aplikacji, które orkiestrują funkcjonalności. Zawiera również model domenowy czyli logikę biznesową. Rdzeń jest reprezentowany przez heksagon (sześciokąt), który za pomocą Portów odbiera polecenia lub zapytania oraz również za pomocą Portów wysyła żądania do innych aktorów zewnętrznych, takich jak bazy danych.

Alistair nie daje instrukcji, jak powinieneś ustrukturyzować kod w swoim rdzeniu, ale Architektura Heksagonalna jest często łączona z Domain Driven Design. Wtedy rdzeń lub sześciokąt zawiera warstwę aplikacji i warstwę domeny pozostawiając warstwy interfejsu użytkownika i infrastruktury na zewnątrz.

Dlaczego Heksagon?

Alistair wybrał sześciokąt, aby ludzie wykonujący rysunek mieli miejsce na wstawianie portów i adapterów zgodnie z potrzebami, nie będąc ograniczonymi przez jednowymiarowy rysunek warstwowy. Termin Architektura Heksagonalna pochodzi od tego efektu wizualnego. Liczba 6 jest nieistotna - można użyć kształtu z n-krawędziami.

Strona sterująca i strona sterowana

W systemie możemy rozróżnić 2 rodzaje aktorów ze względu na to kto inicjuje rozmowę lub jest za nią odpowiedzialny:

Aktor Sterujący (Driving/Primary Actor) to aktor, który steruje rdzeniem - wyprowadza go ze stanu spoczynku w celu wykonania jednej z jej udostępnionych funkcji.
Aktor Sterowany (Driven/Secondary Actor) to taki, którym kieruje rdzeń, aby uzyskać odpowiedzi lub po prostu go powiadomić.

Takie rozróżnienie pozwala również podzielić adaptery:

Adapter Sterujący (Driving/Primary Adapter). Może być kontrolerem, który pobiera dane wejściowe (użytkownika) i przekazuje je do aplikacji za pośrednictwem portu. Adapter Sterujący będzie korzystać z Portu Sterującego, a serwis w rdzeniu zaimplementuje interfejs zdefiniowany przez port, w tym przypadku zarówno interfejs portu, jak i implementacja znajdują się wewnątrz Heksagonu.
Adapter Sterowany (Driven/Secondary Adapter). Na przykład Adapter bazy danych, który jest wywoływany przez rdzeń, aby pobrać określony zestaw danych z bazy danych. Adapter Sterowany zaimplementuje Port Sterowany, a serwis w rdzeniu będzie z niego korzystać, w tym przypadku Port znajduje się wewnątrz Heksagonu, ale implementacja znajduje się w Adapterze, a więc poza Heksagonem.

Korzyści

Architektura Heksagonalna nie jest idealnym rozwiązaniem dla wszystkich aplikacji. Doda ona dodatkowy poziom złożoności, ale sprawdzi się jeżeli potrzebujemy w systemie poniższych elementów.

Opóźnienie w czasie decyzji technicznych
Na początku projektu programista może nie wiedzieć jaka baza danych (lub inna technologia) sprawdzi się najlepiej. Można napisać tymczasowe adaptery, które będą zwracały dane wpisane na sztywno w pliku tekstowym. Rozwiązanie nie sprawdzi się na produkcji, ale umożliwi testy zanim nasza wiedza będzie na tyle duża, aby podjąć najlepszą decyzję.

Prosta zmiana technologii
Nawet jeżeli zdamy sobie sprawę, że wybór technologii był błędny to przełączanie się między technologiami to kwestia napisania nowych adapterów. Porty i Adaptery wpisują się w zasadę Open-Closed z SOLIDa sformułowanego przez Roberta Martina (Wujek Bob). Piszemy nowy kod i nie musimy modyfikować istniejącego.

Odwrócenie zależności
Realizujemy kolejną z zasad SOLID - Dependency Inversion, która mówi, że "Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych - zależności między nimi powinny wynikać z abstrakcji.". DI skutecznie zmniejsza sprzężenie (coupling) między różnymi fragmentami kodu. Mniejszy coupling = mniej uciążliwych zmian w miejscach połączeń.

Po Stronie Sterującej adapter zależy od portu, którego implementacja jest w rdzeniu. Zna tylko metody zagwarantowane przez interfejs dlatego, zależy od abstrakcji.
Po Stronie Sterowanej serwis rdzenia zależy od portu, którego implementacja jest w infrastrukturze.

Lepsza testowalność
System może być testowany w oderwaniu od zewnętrznych zależności. Można podmienić prawdziwe adaptery na testowe.

Koncentracja na domenie
Rdzeń czyli clou naszej aplikacji jest wolny od wpływu technologii. Pozwala to skupić się na domenie, dlatego też Architektura Heksagonalna Często jest łączona z Domain Driven Design.

Domain Driven Laravel

Poniżej zaimplementuje uproszczoną wersje systemu służącego do rezerwacji pokoju w hotelu z użyciem Hexagonal Architecture, Domain Driven Design oraz frameworka Laravel.

Zacznijmy od wyznaczenia warstw naszego systemu. Warto przypomnieć, że Architektura Heksagonalna wspiera DDD przez izolowanie domeny od czynników zewnętrznych. Logika domeny jest zawarta w rdzeniu, który jest częścią wewnętrzną, a reszta to części zewnętrzne. Dostęp do logiki domeny z zewnątrz jest możliwy poprzez porty i adaptery.

Podzielimy system na 3 warstwy: domena (wewnątrz heksagonu), aplikacja (zewnątrz) oraz infrastruktura (zewnątrz).

Poprzez warstwę aplikacji użytkownik wchodzi w interakcję z systemem. Obejmuje punkty wejścia do naszej aplikacji i koordynuje wykonywanie logiki domeny. Zawiera takie elementy jak kontrolery i interfejs użytkownika.
W warstwie domeny znajduje się kod odpowiedzialny za logikę biznesową. Zawiera interfejsy definiujące API do komunikacji z częściami zewnętrznymi, takimi jak baza danych. Jedyna warstwa we wnętrzu heksagonu.
Warstwa infrastruktury to część, która zawiera wszystko czego program potrzebuje do działania, na przykład konfigurację bazy danych i innych narzędzi. Zawiera implementacje interfejsów z warstwy domeny, które zależą od infrastruktury (repozytoria).

Więcej informacji o tym dlaczego tak wyznaczam warstwy we wpisie Architektura warstwowa w Laravelu.

Warstwa domeny

Model Booking:

<?php

namespace Src\Booking\Domain\Models;

use Illuminate\Database\Eloquent\Model;

/**
 * @property int $id
 * @property int $customer_id
 * @property int $room_id
 * @property string $check_in
 * @property string $check_out
 */
class Booking extends Model
{
    //
}

Port sterujący (interfejs w heksagonie):

<?php

namespace Src\Booking\Domain\Contracts;

interface BookingService
{
    public function storeBooking(array $data);
}

Implementacja Portu Sterującego w serwisie domeny (to nie jest adapter), używa Portu Sterowanego:

<?php

namespace Src\Booking\Domain\Services;

use Illuminate\Support\Facades\DB;
use Src\Booking\Domain\Contracts\BookingRepository;
use Src\Booking\Domain\Contracts\BookingService as BookingServiceContract;
use Src\Booking\Domain\Contracts\Events\BookingCreated;
use Src\Booking\Domain\Models\Booking;
use Src\Payment\Domain\Services\StripePaymentService;
use Src\Room\Domain\Contracts\RoomService;
use Symfony\Component\HttpKernel\Exception\UnprocessableEntityHttpException;


class BookingService implements BookingServiceContract
{
    public function __construct(
        private BookingRepository    $bookingRepository,
        private RoomService          $roomService,
        private StripePaymentService $paymentService,
    ) {
    }

    public function storeBooking(array $data): Booking
    {
        DB::beginTransaction();

        try {
            $room = $this->roomService->getRoomById($data['room_id']);

            $booking = $this->bookingRepository->createBooking($data);

            $this->paymentService->charge($booking->getKey(), $room->price);

            DB::commit();
        } catch (\Exception $e) {
            DB::rollback();
            throw new UnprocessableEntityHttpException(__('booking::errors.failed'));
        }

        event(new BookingCreated($booking->getKey()));

        return $booking;
    }
}

Port sterowany (interfejs repozytorium w heksagonie):

<?php

namespace Src\Booking\Domain\Contracts;

use Src\Booking\Domain\Models\Booking;

interface BookingRepository
{
    public function createBooking(array $data): Booking;
}

Warstwa aplikacji

Adapter Sterujący - kontroler, który korzysta z Portu Sterującego:

<?php

namespace Src\Booking\Application\Http\Controllers;

use App\Http\Controllers\Controller;
use Src\Booking\Application\Http\Requests\StoreBookingRequest;
use Src\Booking\Application\Http\Resources\BookingResource;
use Src\Booking\Domain\Contracts\BookingService;
use Src\Booking\Domain\Models\Booking;

class BookingController extends Controller
{
    public function store(StoreBookingRequest $request, BookingService $bookingService): BookingResource
    {
        $this->authorize('create', Booking::class);

        $booking = $bookingService->storeBooking($request->validated());

        return new BookingResource($booking);
    }
}

Warstwa Infrastruktury

Adapter sterowany - implementacja interfejsu repozytorium:

<?php

namespace Src\Booking\Infrastructure\Repositories;

use Src\Booking\Domain\Contracts\BookingRepository as BookingRepositoryContract;
use Src\Booking\Domain\Models\Booking;

class BookingRepository implements BookingRepositoryContract
{
    public function createBooking(array $data): Booking
    {
        return Booking::create([
            'customer_id' => $data['customer_id'],
            'room_id' => $data['room_id'],
            'check_in' => $data['check_in'],
            'check_out' => $data['check_out'],
        ]);
    }
}

Service Container
Warto wspomnieć, że Laravel oferuje świetne narzędzie, które umożliwi połączenie interfejsu z daną implementacją, którym jest Service Container.

Kod aplikacji dostępny jest w serwisie github

Podsumowanie

W przedstawionym przykładzie rdzeń wystawia porty do komunikacji z warstwą aplikacji (kontrolery) oraz bazą danych. Jednak w prawdziwej aplikacji potrzebujemy szeregu innych narzędzi lub zewnętrznych bibliotek jak obsługa cache'u, systemu plików, logowanie, wysyłanie maili, kolejki, sesje, autoryzacja. Laravel oferuje prosty dostęp do tych technologii za pomocą fasad, ale trzymając się ściśle omawianej architektury musielibyśmy z nich zrezygnować. Dla każdej z technologi należałoby zdefiniować interfejs i go zaimplementować w warstwie infrastruktury. Doprowadzony do skrajności, możesz potencjalnie przełączać frameworki bez ponownego kodowania aplikacji. Uważam jednak, że jest to najbardziej brzegowy i nierealistyczny przypadek do, którego nie warto dążyć. Programowanie w Laravelu ma być przyjemne, dlatego stosuj Porty i Adaptery tam gdzie widzisz z tego korzyści. Dla mnie osobiście Architektura Heksagonalna sprawdza się najlepiej jeżeli chcemy osiągnąć Modularny Monolit, ale to już będzie tematem kolejnego wpisu.

Architektura warstwowa w Laravelu

Kamil Kozak — Tue, 20 Sep 2022 20:16:40 +0000

Kiedy tworzymy aplikację, duża jej część nie jest bezpośrednio związana z domeną, ale jest częścią infrastruktury. Typowa aplikacja zawiera dużo kodu związanego z dostępem do bazy danych, dostępem do plików, UI (User Interface).

Gdy kod związany z domeną jest mieszany z innymi warstwami (ponieważ jest to najłatwiejszy sposób, aby wszystko zaczęło działać szybko), staje się niezwykle trudny do czytania i zarządzania. Prowadzi to do niepożądanego sprzężenia (coupling) i może skutkować mniejszą elastycznością w większych aplikacjach. Nie ma izolacji między dwiema warstwami. Sprzęganie zawsze prowadzi do mniejszej elastyczności.

W swojej książce Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans proponuje architekturę 4-warstwową, aby umożliwić izolację między warstwą domeny, która przechowuje logikę biznesową, a pozostałymi 3 warstwami pomocniczymi: interfejs użytkownika, aplikacja, i infrastruktura.

Dlatego podziel złożony program na warstwy które będą zależne tylko od warstw poniżej. Skoncentruj cały kod związany z modelem domeny w jednej warstwie i izoluj go od aplikacji, infrastruktury i interfejsu użytkownika. Obiekty domeny, wolne od odpowiedzialności za wyświetlanie się, przechowywanie itd., mogą koncentrować się na wyrażaniu modelu domeny.

Warstwa Interfejsu Użytkownika (Warstwa Prezentacji/UI)
Odpowiada za prezentowanie informacji i interpretację poleceń użytkownika. Przykładowo dla aplikacji webowych, UI obejmuje swoim zasięgiem przede wszystkim kontrolery. Może zostać połączona z Warstwą Aplikacji, gdyż najważniejsze jest wydzielenie domeny.
Warstwa Aplikacji
Cienka warstwa która koordynuje działanie aplikacji. Definiuje zamierzone zadania programu i steruje obiektami dziedziny (z warstwy niżej) w celu rozwiązania postawionych przed nimi zadań. Nie zawiera logiki ani wiedzy biznesowej. Nie przechowuje stanu obiektów biznesowych, ale może przechowywać stan postępu zadania aplikacji.
Warstwa Domeny
Ta warstwa zawiera informacje o domenie. Serce oprogramowania biznesowego. Przechowuje stan obiektów domeny, którego zapisywanie delegowane jest do warstwy infrastruktury.
Warstwa Infrastruktury
Ta warstwa działa jako biblioteka pomocnicza dla pozostałych warstw. Zapewnia komunikację między warstwami. Implementuje utrwalanie obiektów biznesowych. Zawiera biblioteki pomocnicze dla warstwy Interfejsu Użytkownika itp. Zapewnia komunikację ze światem zewnętrznym.

Na przykład tak może wyglądać typowa interakcja domeny, aplikacji i infrastruktury. Użytkownik chce zarezerwować pokój w hotelu i prosi o to serwis aplikacji w warstwie aplikacji. Warstwa aplikacji pobiera odpowiednie obiekty domeny (encje) z infrastruktury i wywołuje na nich metody do rezerwacji pokoju. Gdy obiekty domeny zakończą działania, usługa aplikacji utrwali obiekty w infrastrukturze.

Powiązanie warstw

Warstwy mają być luźno powiązane, a zależności muszą być jednokierunkowe. Warstwy wyższe mogą używać elementów warstw niższych poprzez wykorzystanie ich interfejsów. Jeżeli na przykład aplikacja chce wysłać wiadomość e-mail, wtedy w warstwie infrastruktury może zostać zlokalizowany interfejs służący do wysyłania wiadomości, zaś elementy warstwy aplikacji mogłyby tylko zażądać jej wysłania. Dzięki temu warstwa aplikacji jest wąsko skoncentrowana na swoim zadaniu i wie, kiedy ma wysłać wiadomość, lecz nie przejmuje się tym, w jaki sposób to wykonać.

Domain Driver Laravel

Tak wygląda próba dopasowania domyślnej struktury Laravela do warstw, które proponuje Evans.

Jeżeli popatrzymy na Eloquent, możemy zobaczyć, że żyje on w warstwie infrastruktury (frameworka) jednak duża część naszej logiki domeny znajduje się w modelach, które Eloquenta rozszerzają. Między warstwą infrastruktury (frameworka) i warstwą domeny zachodzi silne powiązanie (coupling). W Laravelu wbrew zasadom DDD nie położono nacisku na rozdzielenie odpowiedzialności (separation of concerns), ale na czysty i prosty kod. Poszukajmy więc miejsca w którym Laravel i DDD współżyją razem.

Możliwa struktura folderów

Dokumentacje i tutoriale do frameworków zachęcają do grupowania kodu opierając się na szczegółach technicznych czyli kontrolery z kontrolerami, modele z modelami i tak dalej. Przed wyznaczeniem struktury katalogów zgodnie z DDD warto odpowiedzieć sobie na pytanie czy klient prosi o "pracę nad kontrolerami" lub "katalogiem modeli" czy o pracę nad funkcjonalnością obsługi zamówień czy magazynu.

Ponieważ chce zostać wiernym Laravelowi, w rzeczywistości nie zmienię wielu aspektów jego struktury bo nie jest to konieczne. Tutaj zasugeruję prostą strukturę folderów, aby konkretnie zaimplementować to, co omówiliśmy do tej pory.

1) Zaczynamy od domyślnej struktury katalogów Laravela.

2) Tworzymy folder Domain dla warstwy domeny - można to zrobić na 2 sposoby:

a) Umieszczając go w /app (preferowane przeze mnie)

/app/Domain
    |___ /Booking
    |___ /Payment
    |___ /Invoice
        |___ /Actions
        |___ /QueryBuilders
        |___ /Collections
        |___ /DataTransferObjects
        |___ /Events
        |___ /Exceptions
        |___ /Jobs
        |___ /Listeners
        |___ /Models
        |___ /Rules
        |___ /States
    |___ /Shared (funkcjonalności współdzielone)

b) Umieszczając go w /src. Trzeba go dodać w pliku composer.json, aby zarejestrować nową przestrzeń nazw.

    "autoload": {
        "psr-4": {
            "App\\": "app/",
            "Domain\\" : "src/Domain/",
            ...
        }
    },

Nie zapomnij composer dump-autoload.

3) Tworzymy folder per Bounded Context/Domena (Booking, Payment...) w poprzednio dodanym katalogu Domain.

4) Warstawa aplikacji żyje tam gdzie dotychczas czyli w katalogu /app/Http.

a) można pozostać przy domyślnej strukturze wewnątrz /app/Http

/app/Http
    |___ /Controllers
        |___ /Admin
        |___ /Api
        |___ /Front
    |___ /Requests
        |___ /Admin
        |___ /Api
        |___ /Front
    |___ /Resources
        |___ /Admin
        |___ /Api
        |___ /Front
    |___ /ViewModels
    |___ ...

b) ale preferuję odwrócenie tego schematu

/app/Http
    |___ /Admin
        |___ /Controllers
        |___ /Requests
        |___ /Resources
        |___ /ViewModels
    |___ /Api
        |___ /Controllers
        |___ /Requests
        |___ /Resources
    |___ /Front
        |___ /Controllers
        |___ /Requests
        |___ /Resources
        |___ /ViewModels
    |___ /Support (funkcjonalności współdzielone)
        |___ /Controllers
        |___ /Middleware
        |___ Kernel.php

c) a w przypadku dużej aplikacji

/app/Http
    |___ /Admin
        |___ /Booking
            |___ /Controllers
            |___ /Requests
            |___ /Resources
            |___ /ViewModels
        |___ /Payment
            |___ /Controllers
            |___ /Requests
            |___ /Resources
            |___ /ViewModels
        |___ /Invoice
            |___ /Controllers
            |___ /Requests
            |___ /Resources
            |___ /ViewModels
    |___ /Api
    |___ /Front
    |___ /Support (funkcjonalności współdzielone)
        |___ /Controllers
        |___ /Middleware
        |___ Kernel.php

5) Struktura w katalogu /resources, który też jest częścią warstwy aplikacji może naśladować tą z /app/Http

Domena

Katalog domen związany jest z biznesem. W każdej z domen znajdują się foldery na koncepty z Laravela, które odpowiadają za logikę biznesową:

Models
Services
Actions
Events
Jobs
itd

Poza separacją domeny taka struktura me też inne zalety:

Łatwiejsza nawigacja. Wszystko, co związane z zamówieniem, znajduje się w katalogu Order.
Łatwiejsze wdrażanie nowych programistów. W końcu pracujemy w zespołach z innymi programistami. O wiele łatwiej jest wdrożyć nowych deweloperów, jeśli mogę powiedzieć: „jeśli potrzebujesz czegoś związanego z fakturami, możesz przejść do katalogu Domains/Invoices”.

Ta warstwa zawiera Serwisy Domeny (Domain Services). W przypadku gdy logika biznesowa nie pasuje do klasy modelu można umieścić ją w Serwisie Domeny.

Interfejs Użytkownika

W tej warstwie mogą znajdować się kontrolery i widoki. Spełniają one jednak warunki, żeby należeć do warstwy aplikacji dlatego do niej je zakwalifikuje. Ma to większy sens ponieważ warstwa aplikacji w Laravelu jest bardzo cienka. Zwykle jest to miejsce na komendy (command) i command handlery oraz serwisy aplikacji, ale by zachować prostotę w Laravelu tego typu funkcjonalności umieszczam w warstwie domeny.

Aplikacja

W tej warstwie mieszczą się Serwisy Aplikacji (Application Services). Warstwa ta może istnieć jako komponenty inne niż usługi - na przykład kontrolery. Stanowi "C" w architekturze MVC.

Kontroler powinien ograniczyć się do wykonania dwóch rzeczy: przyjęcia żądania i zwrócenia odpowiedzi. Należy stosować podejście “Fat Model, Skinny Controller”. W idealnym przypadku akcja kontrolera powinna zawierać 1-2 linijki kodu. Logika związana z biznesem (domeną) powinna zostać przeniesiona w inne miejsce, w warstwie domeny.

Często nie ma mapowania 1:1 między kontrolerami (aplikacja) i modelami (domena). Dlatego w podejściu, które stosuje aplikacja może korzystać z kilku domen jednocześnie.

Umieść tutaj:

Controllers
Requests
Middleware
Resources
ViewModels

Infrastruktura

W Warstwie Infrastruktury, która bywa też nazwana Warstwą Frameworka żyje Laravel, a także biblioteki/SDK zainstalowane composerem. Ten obszar obejmuje także konfigurację bazy danych i innych modułów Laravela z katalogu config, migracje, seedery, factory.

Podsumowanie

Spojrzenie na architekturę, które przedstawiłem czerpie garściami z DDD i opiera się w głównej mierze na grupowaniu kodu wokół funkcjonalności. Sprawia, że zarządzanie projektem jest łatwiejsze gdy ten się rozrasta.

W Projektowaniu Opartym na Domenie nie chodzi o idealne wyznaczenie warstwy prezentacji ani warstwy aplikacji. DDD to metodologia, której głównym celem jest warstwa domeny. Oznacza to, że DDD nie nakłada ograniczeń dotyczących żadnej warstwy poza warstwą Domeny. To, że ktoś utworzył katalogi „Warstwa aplikacji” i „Warstwa prezentacji”, nie oznacza, że Twoja aplikacja powinna je mieć. Powinieneś tworzyć warstwy po utworzeniu znacznej ilości kodu, który pogrupowałeś i chcesz nazwać tę grupę ze względu na komunikację między programistami i przejrzystość kodu.

Możesz się zastanawiać czy Laravel nie wymaga by klasy znajdywały się w domyślnych folderach. Odpowiedź brzmi: Nie. W rzeczywistości Laravel jest pod tym względem bardzo elastyczny. Jeżeli potrzebujesz zmienić istniejącą strukturę bardzo pomocny w tym jest PhpStorm. Można za jego pomocą przenosić w nowe miejsce klasy lub całe namespace'y i zadba on o zmianę ścieżek importu we wszystkich plikach.

Nie poruszyłem ważnej kwestii separacji warstw, gdyż w tym podejściu jej nie stosuję. Wrócę do tego tematu we wpisie o Architekturze Heksagonalnej.

Czym jest Domain Driven Design (DDD)?

Kamil Kozak — Mon, 12 Sep 2022 23:17:00 +0000

Wpis ten powstał jako próba usystematyzowania mojej wiedzy po przeczytaniu książki "Domain-Driven Design: Tackling Complexity in the Heart of Software" Erica Evansa.

Oprogramowanie jest najczęściej tworzone po to, aby rozwiązywać problemy biznesowe pochodzące z domeny świata rzeczywistego. W podejściu Domain Driven Design musisz od samego początku zrozumieć, że oprogramowanie wywodzi się z tej domeny i jest z nią głęboko powiązane. Mimo, że składa się z kodu nie należy go postrzegać tylko jako obiekty i metody.

W książkach przełożonych na język polski pojęcie "Domain Driven Design" tłumaczone jest jako "Projektowanie Sterowane Domeną", "Projektowanie oparte na dziedzinie", "Projektowanie Dziedzinowe".

Aby stworzyć dobre oprogramowanie, musisz wiedzieć, o co w nim chodzi. Nie możesz stworzyć systemu oprogramowania bankowego, jeśli nie masz dobrego zrozumienia, o co chodzi w bankowości, musisz przedtem zrozumieć tę domenę.

Jak sprawić, by oprogramowanie harmonijnie pasowało do domeny? Najlepszym sposobem na to jest uczynienie oprogramowania odzwierciedleniem domeny. Musi ono zawierać podstawowe koncepcje i elementy domeny oraz precyzyjnie realizować relacje między nimi. Oprogramowanie musi modelować domenę.

Domena. Sfera wiedzy, wpływu lub działalności. Obszar tematyczny, do którego użytkownik stosuje program to domena oprogramowania.

Więc zaczynamy od domeny. Domena jest czymś ze świata rzeczywistego, aby stała się kodem musimy stworzyć abstrakcję domeny. Wiele dowiadujemy się o domenie podczas rozmów z ekspertami domenowymi. Ale ta surowa wiedza nie da się łatwo przekształcić w konstrukcje oprogramowania, chyba, że zbudujemy jej abstrakcję. Na początku będzie niekompletna, ale z czasem będziemy ją ulepszać. Czym jest ta abstrakcja? To model domenowy.

Model. Zestaw abstrakcji który, opisuje wybrany aspekt domeny i który, może być użyty do rozwiązania problemu dotyczącego tej domeny.

Wg Erica Evansa model domeny nie jest konkretnym diagramem. Jest to idea, którą ma przekazać diagram. Model jest istotną częścią projektowania oprogramowania. Potrzebujemy go, aby poradzić sobie z jego złożonością. Kiedy zostanie wyrażony, możemy zacząć projektować kod stosując różne podejścia takie jak Waterfall, Agile, Extreme Programming.

Język wszechobecny

Eksperci domenowi i programiści powinni wymieniać się wiedzą wykopując pojęcia z domeny. Może to być proces chaotyczny, niemniej jednak niezbędny do zrozumienia dziedziny. Takie podejście zwykle ma pewne początkowe trudności ze względu na barierę komunikacyjną. Programiści myślą w kategoriach klas, metod, polimorfizmu, OOP, ale eksperci domenowi prawdopodobnie nic o tym nie wiedzą. Znają się za to na swojej specjalizacji. Projekt napotyka problemy, gdy członkowie zespołu nie mają wspólnego języka do omawiania domeny.

Podstawową zasadą DDD jest użycie języka opartego na modelu. Poproś zespół, aby konsekwentnie używał tego języka w kodzie oraz wszystkich formach komunikacji. Z tego powodu język ten nazywany jest Językiem Wszechobecnym (Ubiquitous Language). Eksperci dziedzinowi powinni sprzeciwiać się terminom których sami nie rozumieją ponieważ oznacza to, że coś jest nie tak.

Czego można używać do języka? Mowy, diagramów lub pisma. Zalecanym sposobem komunikowania modelu jest wykonanie kilku małych diagramów zawierających podzbiory modelu czyli klasy i relacje między nimi. Dokumenty te mogą być nawet rysowane ręcznie, ponieważ są tymczasowe i mogą zostać zmienione w niedalekiej przyszłości zanim model osiągnie bardziej stabilny status. Uważaj na długie dokumenty. Ich napisanie zajmuje dużo czasu i mogą stać się przestarzałe, zanim zostaną ukończone. Możliwa jest również komunikacja za pomocą kodu.

Język Wszechobecny obowiązuje w obrębie jednego Kontekstu Ograniczonego gdyż pojęcia mogą mieć różne znaczenia. "Lot" w zależności od kontekstu może oznaczać start i lądowanie inne definicje odnoszą się do konserwacji samolotu lub biletowania przelotów. Ponieważ każda z tych definicji „lotu” jest jasna wyłącznie we własnym kontekście, to każda powinna zostać ujęta w osobnym Kontekście Ograniczonym. Ujęcie ich wszystkich w jednym wspólnym Kontekście Ograniczonym doprowadziłoby do pomieszania pojęć.

Język Wszechobecny. Język wypracowany wokół modelu domeny i używany przez wszyskich członków zespołu w obrębie Kontekstu Ograniczonego do komunikacji przy pracy nad oprogramowaniem.

Kontekst ograniczony

Każdy model ma kontekst. Kiedy tworzymy aplikację, która ma współdziałać z inną starszą aplikacją, jasne jest, że nowa aplikacja ma własny model i kontekst. Nie mogą być łączone, mieszane ani mylone. Ale kiedy pracujemy nad dużą, aplikacją sami musimy zdefiniować kontekst dla każdego tworzonego modelu.

Po połączeniu kodu opartego na różnych modelach oprogramowanie staje się błędne i trudne do zrozumienia. Dlatego postaraj się umieścić w modelu te elementy, które są ze sobą powiązane i tworzą naturalną koncepcję. Model powinien być na tyle mały, aby można go było przypisać do jednego zespołu. Trudno utrzymać czysty model, gdy obejmuje on cały projekt firmy, ale znacznie łatwiej, gdy ogranicza się do jednego obszaru.

Kontekst Ograniczony (Bounded Context) nie jest modułem. Kontekst Ograniczony obejmuje moduł. Zapewnia ramę, w której model ewoluuje.

Za posiadanie wielu modeli trzeba zapłacić pewną cenę. Musimy określić granicę i relacje między różnymi modelami. Wymaga to dodatkowej pracy. Nie będziemy w stanie przenosić żadnych obiektów między różnymi modelami i nie możemy swobodnie wywoływać zachowania, tak jakby nie było granicy. Jednak korzyści są tego warte.

Na przykład chcemy stworzyć aplikację e-commerce która posiada obsługę zamówień oraz magazynu. Stworzenie osobnego modelu dla każdej domeny spowoduje, że mogą swobodnie ewoluować, a nawet stać się oddzielnymi aplikacjami. Aplikacja magazynu może wysyłać obiekty DTO (Data Transfer Object) zawierające informacje o produkcie do zamówień. Dwa modele można rozwijać osobno i należy zadbać o to, aby działał interfejs między nimi.

Kontekst Ograniczony. Ustalony obszar zastosowania danego modelu. Kontekst pozwala członkom zespołu na jednoznaczne zrozumienie zakresu, obszaru, który ma pozostać spójny, i oddzielenie go od tego, co może zostać zaprojektowane w sposób niezależny.

Continuous Integration

Model nie jest w pełni zdefiniowany od początku. Powstaje, a następnie nieustanie ewoluuje w oparciu o informacje zwrotne z procesu rozwoju. Oznacza to, że do modelu mogą wchodzić nowe koncepcje, a do kodu dodawane są nowe elementy. Dlatego ciągła integracja jest procesem niezbędnym w Ograniczonym Kontekście. Musimy mieć procedurę używaną do scalania kodu. Im szybciej połączymy kod, tym lepiej.

Subdomeny

Domena dzieli się na wiele Subdomen inaczej Poddziedzin (Subdomains) i każda z nich skupia się na mniejszych problemach. Np. E-commerce jako domena składa się z Subdomen: koszyk, płatności czy katalog produktów. W DDD Subdomena jest pojęciem relatywnym. Domena i Subdomena mogą być używane zamiennie. Kiedy używamy słowa Subdomena, podkreślamy, że domena o której mówimy, jest dzieckiem innej domeny wyższego poziomu.

Subdomena która jest częścią świata rzeczywistego wdrażana jest jako Kontekst Ograniczony. Subdomena określa "co" produkt miałby osiągnąć i znajduje się w Przestrzeni Problemów (Problem Space). Kontekst Ograniczony określa "jak" produkt miałby to osiągnąć i leży w Przestrzeni Rozwiązań (Solution Space). W jednym Kontekście Ograniczonym powinniśmy zawrzeć jedną Subdomenę. W niektórych przypadkach w jednym Kontekście Ograniczonym może się znaleźć wiele Subdomen, ale nie jest to najbardziej optymalna postać modelu.

Destylacja

Duża domena ma duży model nawet po wielu refaktoryzacjach. W takich przypadkach może nadejść czas na Destylację. Ideą jest zdefiniowanie Domeny Głównej (Core Domain), która reprezentuję istotę modelu domeny i nie może zostać zaniedbana i nad którą powinni pracować najlepsi programiści. Produktami ubocznymi destylacji będą Subdomeny Generyczne (Generic) i Pomocnicze (Supporting), które będą obejmować inne części domeny.

Mapa kontekstów

Duża aplikacja ma wiele modeli, a każdy ma swój kontekst ograniczony. Choć zespoły powinny pracować nad swoimi modelami, dobrze jest, aby każdy miał wyobrażenie o ogólnym obrazie. Mapa Kontekstów (Context Map) to dokument, który przedstawia Konteksty Ograniczone i relacje między nimi. Mapa kontekstów może być mało szczegółowym diagramem podobnym do tego poniżej.

Ważne, aby wszyscy pracujący nad projektem go podzielali i rozumieli, aby uniknąć nakładania się kontekstów na siebie i problemów gdy system zostanie zintegrowany. Każdy Kontekst Ograniczony powinien mieć nazwę, która jest częścią Języka Wszechobecnego ponieważ pomaga to w komunikacji, gdy mówi się o całym systemie.

Istnieją różne sposoby interakcji między kontekstami:

Partnerstwo (Partnership)

Pomiędzy zespołami zachodzi relacja Partnerstwa. Każdy zespół odpowiada za jeden Kontekst Ograniczony. Wspólnie tworzą one Partnerstwo, w ramach którego posługują się zależnymi zestawami celów. Oznacza to, że obydwa zespoły wspólnie odnoszą sukces lub porażkę.

Wspólne Jądro (Shared Kernel)

Wspólne Jądro, część wspólna dwóch Kontekstów Ograniczonych, opisuje relację pomiędzy dwoma (lub więcej) zespołami, które współdzielą niewielki model. Zespoły muszą być zgodne co do tego, które elementy modelu mają być wspólne.

Klient-Dostawca (Customer-Supplier)

Model Klient-Dostawca opisuje taką relację pomiędzy dwoma Kontekstami Ograniczonymi i ich zespołami, w ramach której Dostawca znajduje się na wyższym szczeblu, Klient na niższym. Dostawca dominuje w tej relacji, ponieważ odpowiada za dostarczanie tego, czego Klient potrzebuje.

Konformista (Conformist)

Relacja Konformisty zachodzi, kiedy istnieją zespoły na wyższym i niższym szczeblu, a zespół wyższego szczebla nie ma żadnej motywacji do zaspokajania potrzeb tego drugiego. Zespół niższego szczebla z różnych względów nie może pozwolić sobie na tłumaczenie Języka Wszechobecnego zespołu wyższego szczebla, więc dostosowuje się on do jego modelu.

Warstwa Zapobiegająca Uszkodzeniu (Anticorruption Layer)

Warstwa Zapobiegająca Uszkodzeniu jest najbezpieczniejszą relacją, w ramach której zespół niższego szczebla tworzy warstwę translacyjną pomiędzy własnym Językiem Wszechobecnym a Językiem Wszechobecnym zespołu wyższego szczebla. Warstwa ta izoluje model niższego szczebla od jego odpowiednika na wyższym szczeblu i tłumaczy ich elementy.

Usługa Otwartego Hosta (Open Host Service)

Usługa Otwartego Hosta definiuje protokół lub interfejs, który daje dostęp do Kontekstu Ograniczonego w formie zestawu usług. Protokół jest „otwarty”, wobec czego wszyscy, którym zależy na integracji z Kontekstem Ograniczonym, mogą skorzystać z niego względnie bezproblemowo.

Język Opublikowany (Published Language)

Język Opublikowany, jest dobrze udokumentowanym językiem do wymiany informacji, umożliwiającym prosty przekaz i tłumaczenie pojęć.

Oddzielne Drogi (Separate Ways)

Oddzielne Drogi opisują sytuację, w której integracja różnych Kontekstów Ograniczonych i stosowanie wielu Języków Wszechobecnych nie przynosi istotnych korzyści. Jeśli na przykład żaden z Języków Wszechobecnych nie może zapewnić oczekiwanej funkcjonalności, najlepiej stworzyć własne, specjalistyczne rozwiązanie w obrębie swojego Kontekstu Ograniczonego i pominąć integrację na potrzeby tego szczególnego przypadku.

Wielka Kula Błota (Big Ball of Mud)

Sytuacja, w której komunikacja przebiega w każdym kierunku. To jest miejsce w którym nie chcesz być.

Czym jest więc DDD w skrócie?

Domain-Driven Design to podejście do wytwarzania oprogramowania, które charakteryzuje:

Skupienie się na domenie.
Odkrywanie modelu we współpracy ekspertów domenowych z programistami.
Posługiwanie się językiem wszechobecnym w granicy kontekstu ograniczonego.

Opisane pojęcia to część Strategiczna DDD czyli filozofia stojąca za Programowaniem Opartym Na Domenie. Projektowanie Strategiczne polega na tworzeniu wstępnego szkicu jeszcze przed przejściem do szczegółów implementacji czyli Projektowania Taktycznego. Skuteczne Projektowanie Taktyczne jest w praktyce niemożliwe, jeżeli nie wychodzi się od Projektu Strategicznego.

Elementy Składowe

Elementy Składowe (Building Blocks) to wzorce, które należy stosować w Projektowaniu Opartym Na Modelu. Stanowią one część Taktyczną DDD.

Domain Driven Laravel

Active Record

Można spotkać się z opinią, że Laravel nie nadaje się do Projektowania Sterowanego Domeną. Jak już wiesz zgodnie z DDD w centrum naszych zainteresowań musi być domena. Domena powinna być wyizolowana i "głupia" w stosunku do świata zewnętrznego. ORM Eloquent jest implementacją wzorca Active Record co oznacza, że że łączy dwa światy: domenę i logikę dostępu do baz danych. Active Record otacza wiersz w tabeli bazy danych, hermetyzuje dostęp do bazy danych i dodaje do tych danych logikę domeny. Tak więc AR jest reprezentacją rekordu bazy danych w skali 1:1. Jeżeli jednak nagniemy tę zasadę DDD Laravel pozwoli zrobić nam wiele fajnych rzeczy. W rzeczywistości Laravel i DDD nie wykluczają się całkowicie.

Co dalej?

W kolejnych wpisach pokażę DDD Taktyczne w Laravelu trzymając się zasad:

Skup się na domenie. Bez tego tracimy istotę DDD.
Nie walcz z frameworkiem. Walka taka jest wyczerpująca i bezcelowa. Chcemy mieć dostęp do dobroci całego frameworka.

W przeciętnej wielkości projekcie ten rodzaj architekty jako całość jest prawie zawsze przesadą. Nie uda się zastosować "czystego" podejścia DDD. Zamiast tego weźmiemy z niego najlepsze części i połączymy je w pragmatyczny sposób.