To będzie opowieść o wrażeniach z książki, a także zostaną omówione niektóre pojęcia i wiedza, które dzięki tej książce zostały nabyte.
Architektura
Czy możesz, czytając ten post, udzielić wyraźnej odpowiedzi na pytanie, czym jest architektura? Czym jest architektura w kontekście programowania i projektowania? Jaką rolę odgrywa? W tym terminie jest wiele niejasności. I wydaje się, że wszystko jest jasne, ale jakoś abstrakcyjnie i bez dokładności. Martin uważa, i ja się zgadzam, że aplikacja ma dwie składowe:
- Zachowanie (behavior) — funkcje i zadania, które program (komponent, serwis) wykonuje.
- Architektura — ten termin w większym stopniu dotyczy zmiany aplikacji.
Ale nawet jeśli aplikacja bardzo dobrze wykonuje zadanie, które powinna, to wcale nie oznacza, że ma dobrą architekturę. Architektura nie dotyczy zachowania aplikacji. Architektura dotyczy łatwości wprowadzania zmian, architektura dotyczy łatwości wdrażania, architektura dotyczy niezależności w rozwoju. Architektura dotyczy szybkości, z jaką nowe osoby w zespole mogą zrozumieć projekt.
I oto jak budować tę architekturę, jak pozbyć się bólu głowy przy małych zmianach wymagań od PM-a lub interesariusza: o tym opowie ta książka.
O autorach
Zanim powiem cokolwiek o tej książce, chciałbym powiedzieć trochę o sobie.
Obecnie jestem Strong Junior Developer, specjalizującym się w tworzeniu usług za pomocą ASP .NET CORE.
Już od roku pracuję w jednej 'galerce', i wydaje mi się, że powoli sobie radzę.
Tę książkę przeczytałem już dwa razy i gorąco ją polecam wszystkim:
- programistom systemów embedded;
- front-endowcom;
- back-endowcom;
- a nawet devopsom.
Ogólnie wszystkim, którzy są w jakiś sposób związani z rozwojem oprogramowania, mam na myśli bezpośredni rozwój różnych systemów, nie uwzględniając tutaj menedżerów sprzedaży i PM-ów (choć też byłoby przydatnie wiedzieć, dlaczego deweloperzy często spędzają dwa razy więcej czasu na zadaniu), polecam przeczytać tę książkę.
A teraz spróbuję uzasadnić, dlaczego tak myślę.
Trochę o autorze tej książki (ponieważ autorytet piszącego ma dla mnie duże znaczenie). Myślę, że mnie zrozumiesz, choć to nie zawsze jest właściwe, ale jeśli coś mówi autorytet w danej dziedzinie – znacznie bardziej ufasz temu, co on mówi. Na przykład, myślę, że bardziej uwierzysz diagnozie postawionej przez lekarza niż przez jakąkolwiek osobę z tłumu (która wyszukała objawy).
Robert Martin, znany również jako Uncle Bob (wujek Bob) – działa w dziedzinie programowania, w różnych systemach (od usług webowych po systemy embedded) od 1970 roku. Jest technicznym konsultantem i architektem, pisał do różnych czasopism technicznych, sam w sobie jest bardzo doświadczonym programistą, a także osobą, która odegrała jedną z kluczowych ról w tworzeniu znanych zasad SOLID (można powiedzieć, że jest ich twórcą). Chcę również dodać, że tę książkę polecił mi mój team leader z ponad 15-letnim doświadczeniem.
O książce
Zależności
Przed przeczytaniem książki przeczytałem wiele artykułów na tym samym Habrze, gdzie pojawiało się słowo „zależność”. Co to jest, kto od kogo zależy, co konkretnie znaczy „zależeć” i jak jakiś klas może zależeć od kogoś?
I w miarę czytania książki zrozumiałem dwie rzeczy:
Zależność – to termin oznaczający, że jakiś klas (komponent, serwis) zna inny klas (komponent, serwis), a ta wiedza na poziomie kodu jest określona (teraz programiści Java, C# i C będą mnie rozumieć) określonym importem namespace. Innymi słowy: macie klas A z namespace Default.Classes i klas B Another.Classes. Jeśli w kodzie źródłowym klas A pojawi się using Another.Classes; – oznacza to, że klas A zależy od klas B.
Aby zrozumieć na schemacie, gdzie jest klas zależny, a gdzie nie – spójrzcie na kierunek strzałki: w 1) strzałka będzie wskazywać od klas A w kierunku klas B. Oznacza to, że klas B jest bardziej niezależny niż klas A. I zmiany w klas A nie wyrządzą żadnej „szkody” klasowi B.
SOLID
Jednym z głównych powodów, które skłoniły mnie do przeczytania tej książki – jest wyjaśnienie zasad SOLID z pierwszej ręki, ponieważ wujek Rob opracował te zasady i można powiedzieć, że to dzięki niemu słyszymy tę nazwę – SOLID.
Dla tych, którzy nie wiedzą — te zasady mówią i sugerują, aby projektować swoje aplikacje zgodnie z 5 zasadami:
S — SRP (Zasada pojedynczej odpowiedzialności)
O — OCP (Zasada otwarte-zamknięte)
L — LSP (Zasada substytucji Liskova)
I — ISP (Zasada segregacji interfejsów)
D — DIP (Zasada inwersji zależności)
Wszystkie te zasady mogą być stosowane na poziomie klas i obiektów, na poziomie modułów i komponentów oraz na poziomie warstw (serwisów).
Jeśli uważasz, że Zasada pojedynczej odpowiedzialności oznacza, że klasa lub moduł powinny robić tylko jedną rzecz — koniecznie musisz przeczytać choćby rozdział na temat SOLID. Ponieważ ta definicja, która została podana powyżej, to konsekwencja, a nie definicja samej zasady.
O inwersji zależności
Szczególną uwagę chcę zwrócić na wyjaśnienie Zasady inwersji zależności (tej, która jest D w SOLID). W trakcie czytania książki zrozumiałem, że to nie tylko zasada, ale także mechanizm i narzędzie, dzięki któremu możesz zmieniać kierunek swoich zależności i sprawić, że np. logika biznesowa (DOMENA) będzie niezależna od detali implementacji warstwy dostępu do danych (DAL).
Chociaż sama zasada, obok innych w SOLID, oznacza nieco coś innego niż mechanizm, sam mechanizm jest stosowany przez całą książkę i jest jednym z podstawowych metod inwersji oraz zmiany kierunku swoich zależności, który, nota bene, jest używany w DDD.
O podejmowaniu decyzji architektonicznych
Bardzo często w książce będzie wspomniana zasada dotycząca podejmowania ważnych decyzji architektonicznych: o tym, jaką bazę danych zastosować, jaki framework użyć, jaką bibliotekę podłączyć, co wykorzystać jako silnik wyszukiwania itd.
Otóż autor uważa: powinieneś jak najmniej podejmować tego typu decyzji. Ponieważ wymagania mogą się zmieniać, ograniczenia dotyczące wydajności również, a sama składnik behawioralny ma tendencję do zmiany. W trakcie rozwoju jakieś rozwiązanie może okazać się mniej efektywne niż inne, mniej wygodne niż inne. A siła twojej architektury będzie określać, jak szybko i bezboleśnie będziesz w stanie zamienić jedną technologię na drugą (o czym zresztą wspomina OCP).
Na przykład, nagle postanowisz użyć zamiast Postgresql MongoDb, lub w ogóle plików, lub użyć danych mockowanych, operacje na których będą przeprowadzane w pamięci. A w niektórych warunkach — może to wymusić przepisanie niemal całej logiki.
Aby uniknąć takich sytuacji, możemy zastosować pewne mechanizmy, które znacznie oddalą czas podejmowania decyzji. Jednym z tych mechanizmów jest abstrakcja.
Wzmianki o DDD
DDD — Domain Driven Design — to podejście do tworzenia usług złożonych z bogatą logiką biznesową, krytyczną na zmiany, które ma na celu maksymalne zrozumienie ze strony kierownictwa projektu (PM-ów, menedżerów sprzedaży itp.) przez zwykłych pracowników. To znaczy, że pomiędzy wszystkimi członkami projektu powinien istnieć język wspólny, aby każdy mógł zrozumieć drugiego i aby wszyscy myśleli w jednym obszarze z tymi samymi zasadami biznesowymi.
Jeśli jesteś zwolennikiem DDD, chcesz nim być lub nie rozumiesz tego, ale chcesz zrozumieć — ta książka jest konieczna do przeczytania, zwłaszcza druga część książki.
Tutaj autor wyjaśnia istniejący Zasady Zależności (Dependency Rule) i dlaczego, stosując go, zbudujesz poprawną architekturę aplikacji. Dlaczego zależności powinny kierować się w stronę komponentów wysokiego poziomu. domenę (Komponent wysokiego poziomu) powinien być niezależny od infrastruktury i jak to ułatwi ci wdrażanie i rozwój.
Abstrakcjonowanie
Wujek Rob opowiada również o tym, jak szczegóły realizacji mogą zaszkodzić twojemu systemowi i uniemożliwić mu dalszą ewolucję bez bólu.
Pamiętaj!
Baza danych to detal realizacji.
Klienci (Web, Mobile, itp.) to detale realizacji.
Frameworki to szczegóły realizacji.
Od tego wszystkiego trzeba maksymalnie się abstrahować i nie być od tego zależnym, stosując opisany wyżej Zasada Inwersji Zależności z interfejsami i abstrakcjami, Zasady Zależności i inne mechanizmy.
Metody budowy modułów
Ten rozdział szczególnie mi się podobał jako deweloperowi usług w ASP .NET CORE. Mówi się w nim o metodach budowy jednolitej architektury usługi z gotowych komponentów.
Robert opisał 4 możliwe schematy podziału warstw.
Daje do zrozumienia, dlaczego tak często stosowany mechanizm architektury trzywarstwowej: UI (kontrolery), Usługi (Domena), DAL (Baza Danych) — jest znacznie gorszy w porównaniu do innych. Widziałem niewiele projektów, ale w każdym, na przykład w mikroserwisie, na backendzie stosuje się właśnie architekturę trzywarstwową.
Często stosuje się architekturę jeden-komponent-jeden-serwis. Ogólnie obie są w porządku, ale ta ma dość wiele wad w porównaniu na przykład do architektury opartej na DDD, szczególnie w przypadku usług krytycznych dla zmian i złożonych.
I oto kończy się przegląd tej książki. Sama książka bardzo mi się podobała, nie żałuję przeczytania, dziękuję autorowi. Drogi Czytelniku, dziękuję za uwagę, nie oceniajcie surowo – ta publikacja jest oparta na wrażeniach z książki oraz moim osobistym entuzjazmie.
Źródło: habr.com
