Jak radzić sobie z projektami o wysokiej złożoności? Jak organizować kod, aby uzyskać wysoki poziom elastyczności rozwiązania? Prezentacja stanowi krótkie wprowadzenie do świata architektury oprogramowania. Omówiona zostanie przykładowa implementacja z wykorzystaniem frameworka ASP .NET Core oraz korzyści płynące z zastosowania wzorców Clean Architecture

1. Hello Clean Architecture
Aleksander Stelmach
Senior Software Developer at Future Processing

2. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Czy zdarzyło Ci się pracować z kodem napisanym przez
kolegę lub koleżankę?
Jakie trudności napotkaliście podczas współpracy?

3. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
- 150 - 200 serwisów w środowisku produkcyjnym
- ok. 500 inżynierów zaangażowanych w projekt
- system działający w 9 państwach
- ok. 1000000 zamówień dziennie
- +10 mln pobrań w Google Play Store (iOS duuuużo więcej)
Mój ostatni projekt

4. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Złożoność rzeczywistych projektów informatycznych jest
bardzo wysoka
Jak sobie z nią radzić?

5. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
https://github.com/alstelmach/hogwart-web-api-spaghetti.git
https://github.com/alstelmach/hogwart-web-api-clean-architecture

6. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
1. Jeżeli wiek studenta jest < 11 lub > 18 – nie przydzielaj do domu
2. Student powinien być przydzielony do pierwszego domu w którym spełnia warunki
przyjęcia. Warunki przyjęcia sprawdzane są kolejno: Slytherin, Gryffindor, Ravenclaw,
Hufflepuff
3. Aby przyjąć studenta do Slytherinu, student musi być wężousty i ambitny
4. Aby przyjąć studenta do Gryffindoru, student musi mieć min. 180 cm wzrostu
5. Aby przyjąć studenta do Ravenclaw, student musi grać w Quidditcha
6. Żeby zostać przyjętym do Hufflepuff, nie trzeba spełniać żadnych warunków
7. Jeżeli dom do którego student ma zostać przydzielony, posiada nieparzystą liczbę
studentów, należy wylosować dom (może zostać wylosowany ten sam dom)
Przydzielenie studenta do domu – wymagania biznesowe

7. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Hogwart Spaghetti

8. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

9. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
- mało czytelne, ciężko się połapać
- kod biznesowy przemieszany z infrastrukturą
- zasadniczo działa

10. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Jakie wymierne zagrożenia niesie za sobą taki design?

11. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
1. Zaimplementować możliwość przeniesienia studenta do innego domu
2. Jeżeli student jest niski, absolutnie nie może zostać przydzielony do Slytherinu
3. Zmienić bazę danych z której korzysta aplikacja
Changes requested - przykłady:

12. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

13. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Błąd – w propozycji nie sprawdza się warunków przyjęcia do danego
domu. Przykładowo ktoś niski może wylądować w Gryffindorze –
złamany został biznesowy wymóg klienta
Choć przykład jest mocno uproszczony, to wierzcie mi na słowo – takie
sytuacje występują bardzo często ☺

14. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
1. Trudno namierzyć miejsce w kodzie gdzie należy wprowadzić zmiany
2. Ciężko jest kolaborować z współpracownikiem, np. kolega zmienia bazę danych, a ja
modyfikuję reguły biznesowe (ponieważ kod domenowy jest przemieszany z
właściwościami infrastruktury, aplikacji itp.)
3. Nie da się przewidzieć jak zachowa się kod po dokonaniu zmian, łatwo popełnić błąd,
nie zauważyć czegoś
Przykładowe trudności przy wprowadzaniu zmian

15. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Wspomniane trudności faktycznie
przekładają się na kondyncję biznesu klienta
1. Trudno namierzyć miejsce w kodzie gdzie należy wprowadzić zmiany -> wysoki koszt
wprowadzania zmian
2. Ciężko jest kolaborować z współpracownikiem, np. kolega zmienia bazę danych, a ja
modyfikuję reguły biznesowe (ponieważ kod domenowy jest przemieszany z
właściwościami infrastruktury, aplikacji itp.) -> wysoki koszt wprowadzania zmian
3. Nie da się przewidzieć jak zachowa się kod po dokonaniu zmian, łatwo popełnić błąd,
nie zauważyć czegoś -> wysokie ryzyko poniesienia dużych kosztów związanych z
błędami,“związane ręce przy designowaniu własnego produktu”,

16. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Hogwart Web API with Clean Architecture

17. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

18. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

19. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

20. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
1. Zaimplementować możliwość przeniesienia studenta do innego domu
2. Jeżeli student jest niski, absolutnie nie może zostać przydzielony do Slytherinu
3. Zmienić bazę danych z której korzysta aplikacja
Changes requested - przykłady:

21. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
1. Zaimplementować możliwość przeniesienia studenta do innego domu
2. Jeżeli student jest niski, absolutnie nie może zostać przydzielony do Slytherinu
3. Zmienić bazę danych z której korzysta aplikacja
Changes requested - przykłady:

22. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

23. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

24. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Zmiana podejścia w trakcie implementacji spowodowała, że
naszemu koledze “trudniej” było popełnić błąd podczas
pracy nad endpointem do przenoszenia studentów

25. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Źródło: https://github.com/devmentors/Confab

26. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Clean Architecture
Clean Architrecture pozwala ogarnąć ogrom kodu z którym
przyjdzie nam się zmierzyć, a także zminimalizować ryzyka
o których wspomniano wcześniej

27. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Źródło: https://github.com/devmentors/Confab

28. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Domena
// ToDo: przykład z hogwart web api

29. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Domena
1. Istotą warstwy domeny jest modelowanie reguł biznesowych, które implementujemy
w ramach wykonywania projektu
2. Jest odizolowana od wszelkiego rodzaju “informatycznego brudu” tj. wolna od pojęć
takich jak
1. Baza danych
2. Protokoły sieciowe
3. Message broker
4. itp. itd.
3. Istnieją pewne narzędzia, które pomagają modelować warstwę domeny w mikroskali,
np. taktyczne DDD

30. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
1. Jeżeli wiek studenta jest < 11 lub > 18 – nie przydzielaj do domu
2. Student powinien być przydzielony do pierwszego domu w którym spełnia warunki
przyjęcia. Warunki przyjęcia sprawdzane są kolejno: Slytherin, Gryffindor, Ravenclaw,
Hufflepuff
3. Aby przyjąć studenta do Slytherinu, student musi być wężousty i ambitny
4. Aby przyjąć studenta do Gryffindoru, student musi mieć min. 180 cm wzrostu
5. Aby przyjąć studenta do Ravenclaw, student musi grać w Quidditcha
6. Żeby zostać przyjętym do Hufflepuff, nie trzeba spełniać żadnych warunków
7. Jeżeli dom do którego student ma zostać przydzielony, posiada nieparzystą liczbę
studentów, należy wylosować dom (może zostać wylosowany ten sam dom)
Przydzielenie studenta do domu – wymagania biznesowe

31. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Zacznij od domeny!

32. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Warstwa aplikacji

33. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Warstwa aplikacji
1. Istotą warstwy aplikacji jest modelowanie tzw. przypadków użycia
2. Operuje na modelach dziedziny

34. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Warstwa infrastruktury

35. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Warstwa infrastruktury
1. Infrastruktura zawiera wszystko to co jest konieczne do działania naszego systemu,
ale nie jest istostne z punktu widzenia biznesu
2. Tu znajdują się konkretne implementacje abstrackji zdefiniowanych w niższych
warstwach

36. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Zalety Wady
 Wysokie maintainability
 Separation of concerns
 Wysoka testowalność kodu
 Wysokie flexibility
 Loose coupling
 W prostych CRUD’owych aplikacjach
stosowanie wzorca “na siłę” może się
skonczyć overengineeringiem
 Boilerplate w prostych aplikacjach
 Jest trudne (nieumiejętna
implementacja może nie gwarantować
nam wspomnianych zalet, natomiast I
tak wyprodukujemy dużo kodu w
stosunku do “prostszych” podejść)

37. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Clean Architecture w aplikacji ASP .NET Core - wskazówki
1. Utwórz projekty odpowiadające omówionym warstwom. Ustaw referencję pomiędzy
projektami w następujący sposób
XXX.Domain <- XXX.Application <- XXX.Infrastructure <- XXX.Api
2. Wykorzystaj interfejsy jako porty do zależności danej warstwy np. IHouseRepository

38. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

39. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h

40. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
Jak rozwijać się w temacie?
1. Clean Architecture: A Craftman’s Guide to Software Structure and Design (Robert C.
Martin Series)
2. Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
3. Samodzielne eksperymentowanie
4. Open source np:
1. https://github.com/jasontaylordev/CleanArchitecture
2. https://github.com/ardalis/CleanArchitecture
3. https://github.com/devmentors/Confab
5. Kursy np. DevMentors, ma kilka fajnych kursów gdzie to dobrze tłumaczą
6. ChatGPT + stackoverflow ☺
7. https://learn.microsoft.com/en-us/dotnet/architecture/

41. H e l l o C l e a n A r c h i t e c t u r e | A l e k s a n d e r S t e l m a c h
astelmach@astelmach.dev
kontakt@dpto.pl
https://www.linkedin.com/in/alstelmach/