Kończąc czytać książkę „Czysta Architektura” Wujka Boba, natknęłam się na rozdział poświęcony organizacji elementów aplikacji. Przedstawił on 4 przykłady różnych architektur tego samego systemu.
Zacznijmy od pierwszego typu architektury na przykładzie mojej aplikacji BoardGamesNook.
Pakowanie w warstwy – 3 warstwy
Tak pokrótce wygląda schemat architektury w mojej aplikacji. Mamy kontroler BoardGameController, który używa interfejsu IBoardGameService. Może on deklarować takie metody jak Get() czy Add(), które są odpowiedzialne za logikę aplikacji. Implementacja interfejsu BoardGameService używa interfejsu IBoardGameRepository. Może on definiować metody Get() i Add(), które bezpośrednio wywołają zmiany na bazie danych.
W tej architekturze widzimy 3 odrębne warstwy:
- kontrolerów (BoardGameController) – kod dla sieci WWW,
- serwisów (IBoardGameService, BoardGameService) – logika biznesowa,
- repozytoriów (IBoardGameRepository, BoardGameRepository) – dane.
Interfejsy są publiczne (kolor zielony), natomiast ich implementacje już niekoniecznie (kolor czerwony). Możemy się dostać osobno do każdej z warstw (kolor szary) i np. ją przetestować.
Schemat zależności
Zalety
– prosta architektura
– popularna
– najczęściej używana przy rozpoczynaniu projektów
Wady
– jeśli chcemy coś zmienić w warstwie bazodanowej, to ma to wpływ na warstwę logiki biznesowej
Porty i adaptery – 3 warstwy
Żeby uniknąć głównej wady wcześniejszego rozwiązania, można użyć architektury portów i adapterów.
Schemat architektury wygląda podobnie, jak w poprzednim przykładzie, aczkolwiek zmieniła się zawartość warstw. Schemat zależności również uległ zmianie,
Schemat zależności
Zalety
– zmiana w warstwie bazodanowej nie wpływa na serwisy
Wady
– UI ma zależność do bazy danych (nieświadomy programista może w kontrolerze użyć połączenia do bazy danych)
Pakowanie według funkcji – x warstw
Od pierwszego przykładu to podejście różni się tym, że jest to podział pionowy. Dzielimy architekturę ze względu na funkcje. W moim przypadku mogłyby to być funkcje dotyczące:
– operacji na obiektach BoardGame (BoardGameController, BoardGameService, BoardGameService, BoardGameRepository, BoardGameRepository),
– operacji na obiektach GameTable (GameTableController, GameTableService, GameTableService, GameTableRepository, GameTableRepository),
– itp.
Co znaczy, że jest x warstw? To znaczy, że jest tyle warstw, ile funkcjonalności. W moim przypadku byłyby to BoardGameProject, GameTableProject itp. Każdy taki projekt składałby się z części UI (kontroler), Logiki (serwisy) i Bazy danych.
Schemat zależności
Zalety
– łatwo dodać nową funkcjonalność
– prosta edycja funkcjonalności
Wady
– wiele projektów
– możliwe wiele zależności między projektami
– częsta duplikacja kodu (można utworzyć dodatkową warstwę Common)
Pakowanie według komponentów – x+1 warstw
W ostatnim przykładzie widzimy x + 1 warstw. Pierwsza jest warstwa kontrolerów (BoardGameController, GameTableController), a kolejnymi specjalne pakiety dotyczące funkcjonalności związanymi z obiektami BoardGame i GameTable. Jak widać, nie można spoza pakietu dostać się interfejsu IBoardGameRepository ani jego implementacji BoardGameRepository.
To rozwiązanie jest hybrydą tych opisanych powyżej. Oddziela ono interfejs użytkownika od komponentów. Na taki komponent składa się logika biznesowa i dane.
Schemat zależności
Zalety
– łatwo dodać nową funkcjonalność
– prosta edycja funkcjonalności
– wydzielona część UI
Wady
– wiele projektów
– możliwe wiele zależności między projektami
– częsta duplikacja kodu (można utworzyć dodatkową warstwę Common)
A może coś innego?
A jakiej architektury Ty używasz w swoich projektach? Jakie są jej wady i zalety? Podziel się swoją wiedzą.
Podoba Ci się to, co tworzę? Chcesz dostawać informacje o:
– wydarzeniach, które organizuję lub wspieram (np. konferencje, meetupy, webinary)
– inicjatywach, które organizuję lub wspieram (np. GeekWeekWro, DevAdventCalendar)
– moich prelekcjach, kursach i szkoleniach
– wyróżnionych artykułach z mojego bloga
0% SPAMu, 100% informacji! Krótko i na temat.
Programmer-girl Weronika Mularczyk 
cqrs, event sourcing
PolubieniePolubione przez 1 osoba
Może podzielisz się plusami i minusami takich rozwiązań?
PolubieniePolubienie