Czysta architektura - Clean Architecture

Czysta architektura albo oryginalnie z angielskiego Clean Architecture, to książka autorstwa Roberta C. Martina, czyli popularnego Wujka Boba. Często jest to pozycja, która promowana jest jako "pozycja obowiązkowa dla każdego programisty Javy", podobnie, jak np. Czysty Kod (Clean Code). Czysta architektura jest jednak książką do dużo węższego grona odbiorców, którzy chcą lepiej zrozumieć ogólne założenia tworzenia aplikacji. Zdecydowanie nie jest to książka dla każdego, o czym też wspomnę w tej recenzji. Książkę czytałem w wersji angielskiej i na niej się tutaj skupię.

Dla kogo jest ta książka

No właśnie. Zacznijmy od podstawowego pytania, czyli kto powinien sięgnąć po tę książkę? Na okładce możemy przeczytać podtytuł Struktura i design oprogramowania. Przewodnik dla profesjonalistów. Kim jest jednak ten profesjonalista? Po lekturze książki dochodzę do wniosku, że na pewno nie jest to programista, który szuka odpowiedzi na nurtujące go odpowiedzi dotyczące struktury kodu i konkretnych wskazówek, które mógłby od razu zacząć stosować w swoim kodzie. Książka jest raczej ogólnym wstępem do tematu projektowania oprogramowania i wprowadzeniem do tego, jak myśleć w sposób obiektowy. Autor w wielu miejscach nawiązuje do swoich doświadczeń, które jednak z perspektywy współczesnego programisty są bardziej lekcją historii, lub lekturą do poduszki, a nie twardą i użyteczną wiedzą. Zresztą ostatnich kilkadziesiąt stron książki autor sam określił jako krótką autobiografię.

Książka jest dobrym wyborem dla osób, które chcą wrócić do korzeni i uporządkować swoją wiedzę na temat programowania obiektowego. Nie jest to jednak książka dla praktyków . Jeżeli oczekujesz od książki tego, że znajdziesz w niej wiedzę, którą strona po stronie możesz przekładać na swój kod, albo oczekujesz jakichś ćwiczeń, to się zawiedziesz. Nie ma tutaj prawie wcale namacalnych przykładów kodu, ani np. przedstawienia struktury projektu wykorzystującego czystą architekturę.

Zawartość

Część I. - Wprowadzenie

Autor przedstawia argumenty, dzięki którym stara się przekonać czytelnika do tego, że alternatywą dla dobrej architektury nie jest "brak architektury", tylko zła architektura. Zła architektura prowadzi do tego, że koszty utrzymania oprogramowania mogą wzrosnąć do poziomów, które mogą wpływać bardzo negatywnie na funkcjonowanie organizacji.

Część II. - Paradygmaty programowania

Ciekawy rozdział stanowiący podsumowanie różnych paradygmatów:

• Programowania strukturalnego,
• Programowania obiektowego,
• Programowania funkcyjnego.

Jest to krótkie wprowadzenie do różnic pomiędzy nimi i wskazanie, dlaczego raczej nie powstaną już inne paradygmaty programowania.

Część III. - SOLID

Ta część książki poświęcona jest 5 zasadom wchodzącym w skład mnemonika SOLID. Jest to bardzo wartościowy fragment, w którym można sobie uzmysłowić, że proste zasady, które wiele osób stosuje intuicyjnie, mają duży wpływ na architekturę naszej aplikacji. Można tutaj odkryć, albo przypomnieć sobie fakt, że wiele osób błędnie interpretuje zasadę "S", czyli Single Responsibility Principle, jako "klasa, lub metoda powinna robić tylko jedną rzecz", co w rzeczywistości ma niewiele wspólnego z tym co ta zasada tak naprawdę znaczy.

Część IV. - Komponenty

SOLID jest zestawem zasad, które możemy stosować w kodzie, natomiast Wujek Bob przedstawia także dodatkowe reguły, które można stosować do komponentów i interakcji między nimi. Komponenty z perspektywy Javy to pliki .jar, między którymi mogą zachodzić różne zależności. Dowiesz się tutaj m.in. dlaczego cykle między komponentami są złe albo co oznacza stabilność.

Część V. - Architektura

Po tym dosyć długim, ale w dużej mierze potrzebnym wstępie, dochodzimy do sedna, czyli architektury. Osobiście za największą wartość z tego rozdziału uważam to, żeby przypomnieć sobie, że programowanie obiektowe nie polega na oddzielaniu od siebie modelu danych rozumianych jako anemiczne klasy, które są tylko prostym kontenerem na dane od logiki aplikacji ukrytej w warstwie usług, tylko na łączeniu tych dwóch światów. Obiekty mogą mieć zarówno stan, jak i zachowanie. Model domenowy Twojej aplikacji nie musi i najczęściej nie powinien wyglądać tak, jak dane, które są używane przez klienta, i np. zwracane później przez restowe punkty krańcowe.

Część VI. - Detale

W tej części nacisk jest położony na to, że rzeczy takie jak wybór bazy danych, czy frameworka webowego, to tak naprawdę tylko detale. Często rozpoczynamy tworzenie aplikacji od wyboru bazy danych i frameworka, bo z perspektywy programisty jest to bardziej sexy. Łatwo jest myśleć godzinami nad tym, czy użyć Spring Boota, czy Quarkusa, czy użyć bazy relacyjnej, czy obiektowej. Najczęściej prowadzi to jednak do tworzenia aplikacji w metodologii "database driven design", czyli nie myślimy o architekturze naszej aplikacji w ramach paradygmatu obiektowego, tylko uzależniamy go od struktury tabel w bazie danych.

Czysta architektura przeciwstawia się takiemu podejściu i na pierwszym miejscu stawia domenę i model obiektowy, a bazę danych, czy sposób komunikacji z naszą domeną odsuwa w czasie - im dalej, tym lepiej.

W rozdziale tym znajdziesz też fajne uporządkowanie kwestii pakietowania w ramach projektu. Jeżeli zastanawiasz się, czy lepiej używać podejścia package by layer , package by feature , czy może jeszcze zaproponowanego przez autora package by component, to tutaj znajdziesz odpowiedzi.

Część VII. - Appendix

Głównie wspomnienia autobiograficzne autora.

Podsumowanie

Książka jest dobrym wyborem dla osób, które szukają technicznego czytadła do poduszki, ale nie będą oczekiwały od niej zbyt wiele w kwestii praktycznych porad. Jeżeli szukasz kodu i konkretów, to się zawiedziesz. Zdecydowanie nie jest to książka, która zmieni Twoją programistyczną karierę, ale może sprawić, że w Twojej głowie zapali się kilka lampek i pojawią się dodatkowe pytania. Próba znalezienia odpowiedzi na te pytania sprawi, że zbliżysz się jeszcze bardziej do czystej architektury.

Moja ocena: 4 / 5