Wraz z rozwojem aplikacji webowych w ASP.NET Core łatwo wpaść w pułapkę rosnącego bałaganu w kodzie. Klasy puchną, zależności mieszają się, a projekt staje się trudny w utrzymaniu, tzw. "spaghetti code". Czysta Architektura (Clean Architecture) to podejście projektowe, które pomaga uporządkować kod poprzez wyraźny podział odpowiedzialności. Dzięki niemu logika biznesowa jest odseparowana od szczegółów technicznych (jak bazy danych czy interfejsy użytkownika), co ułatwia rozwój, testowanie i utrzymanie aplikacji. W tym artykule wyjaśnię, na czym polega Czysta Architektura i jak zastosować ją w projektach ASP.NET Core, aby utrzymać porządek w kodzie.
Czym jest Czysta Architektura?
Czysta Architektura jest często przedstawiana za pomocą koncentrycznych kręgów (tzw. "architektura cebulowa"). W centrum znajduje się rdzeń aplikacji (logika biznesowa: encje, interfejsy, usługi domenowe), a na zewnątrz warstwy zewnętrzne: interfejs użytkownika (UI) oraz infrastruktura. Zależności są odwrócone, warstwy zewnętrzne zależą od wewnętrznych, ale nigdy odwrotnie. Dzięki temu np. logika domenowa nie wie nic o szczegółach bazy danych czy interfejsu webowego. Takie podejście sprzyja testowaniu i łatwym modyfikacjom, szczegóły implementacyjne (baza danych, usługi zewnętrzne itp.) można zmienić lub zastąpić bez naruszania centralnej logiki biznesowej.
Czysta Architektura opiera się na zasadzie Odwrócenia Zależności (Dependency Inversion) z SOLID, komponenty wyższego poziomu (biznesowe) nie powinny zależeć od komponentów niskopoziomowych (infrastrukturalnych), lecz obie warstwy od abstrakcji. W praktyce oznacza to, że warstwa rdzenia definiuje interfejsy i kontrakty, a warstwa zewnętrzna dostarcza ich implementacje. Podejście to było znane pod różnymi nazwami - Hexagonal, Ports and Adapters, Onion Architecture, jednak wszystkie sprowadzają się do podobnych zasad architektury zorientowanej na domenę (logikę biznesową) zamiast na dane.
Zastosowanie Clean Architecture w ASP.NET Core
Jak wprowadzić Czystą Architekturę w typowym projekcie ASP.NET Core? Najlepiej podzielić rozwiązanie na 3 główne części (warstwy), z których każda ma ściśle określoną rolę:
1. Rdzeń aplikacji (Core / Domain) – zawiera logikę biznesową i model domenowy. Tu definiujemy klasy domenowe (np. encje reprezentujące dane biznesowe), interfejsy oraz logikę domenową (np. usługi działające na encjach, wzorce DDD). Żadna klasa w tej warstwie nie powinna zależeć od ASP.NET, bazy danych ani innych szczegółów infrastruktury. Jeśli potrzebujemy przekazywać proste dane między warstwami, można tu również zdefiniować DTO (Data Transfer Objects) pozbawione zależności zewnętrznych.
2. Infrastruktura – zawiera szczegóły techniczne i implementacje interfejsów zdefiniowanych w rdzeniu. Znajdą się tu np. klasa kontekstu Entity Framework (DbContext), migracje bazy danych oraz konkretne repozytoria i serwisy integrujące z zewnętrznymi systemami (np. implementacja interfejsu IEmailSender wysyłająca e-maile, dostęp do systemu plików, API zewnętrzne). Warstwa infrastruktury zależy od rdzenia (aby móc użyć jego interfejsów i modeli), ale ważne jest, by nie nastąpiło odwrotne powiązanie, rdzeń nadal nic nie wie o szczegółach baz danych czy innych systemów.
3. Warstwa prezentacji (UI) – to nasz projekt ASP.NET Core (np. aplikacja MVC, Razor Pages albo Web API). Ta warstwa odpowiada za interakcję z użytkownikiem lub klientem: zawiera kontrolery, modele widoków, strony Razor, ewentualnie komponenty Blazor czy minimal APIs, wszystko, co jest specyficzne dla interfejsu webowego. Warstwa UI referencjuje rdzeń aplikacji (aby korzystać z definicji interfejsów, modeli i logiki biznesowej) i ewentualnie infrastrukturę, tylko w celu zarejestrowania zależności. Idealnie kod w kontrolerach i innych częściach UI korzysta tylko z abstrakcji (interfejsów) zdefiniowanych w rdzeniu. Bezpośrednie używanie klas z infrastruktury w kontrolerach nie jest zalecane.
W startupie aplikacji następuje tzw. composition root, konfigurujemy tam kontener DI i podpinamy implementacje do interfejsów. Przykładowo, jeśli w rdzeniu mamy interfejs IProductRepository, a w infrastrukturze jego implementację EfProductRepository korzystającą z Entity Framework, to w warstwie UI rejestrujemy zależność przez DI:
services.AddScoped<IProductRepository, EfProductRepository>();Dzięki temu kontroler w warstwie UI może przyjmować w konstruktorze zależność IProductRepository, nic nie wiedząc o szczegółach EfProductRepository ani o tym, jak dokładnie dane są przechowywane. Całe "wirowanie" zależności dokonuje się w jednym miejscu, przy starcie aplikacji.
Uwaga: Niektórzy początkujący programiści obawiają się, że podział aplikacji na wiele projektów to przerost formy. W przypadku Czystej Architektury mówimy jednak zazwyczaj tylko o trzech głównych projektach, co nie jest wielkim narzutem nawet dla średnio złożonych aplikacji. Korzyści z lepszej organizacji kodu szybko wynagradzają tę niewielką dodatkową strukturę.
Podsumowanie
Czysta Architektura pomaga zaprowadzić porządek w projektach ASP.NET Core poprzez rozdzielenie warstw odpowiedzialności i odwrócenie zależności. Rdzeń aplikacji skupia logikę biznesową i definiuje kontrakty, a wszystkie szczegóły (bazodanowe, plikowe, interfejsy UI) są trzymane na obrzeżach i implementowane w zewnętrznych warstwach infrastruktury. Taki układ ułatwia rozwój nowych funkcjonalności (bo jasno wiemy, gdzie co dodać), refaktoryzację oraz testowanie, możemy np. testować logikę domenową bez odpalania bazy danych czy serwera WWW[3].
Stosując Czystą Architekturę w ASP.NET Core, zyskujemy aplikację łatwiejszą w utrzymaniu i odporniejszą na zmiany technologiczne. Gdy za rok postanowimy zmienić np. silnik bazy danych albo interfejs użytkownika, dobrze zaprojektowany rdzeń pozostanie niemal nietknięty, wystarczy podmienić warstwę infrastruktury lub UI, implementując te same interfejsy. To sprawia, że nasz kod żyje dłużej i skupia się na tym, co najważniejsze - logice biznesowej.
Na koniec, jeśli chcesz zobaczyć Czystą Architekturę w praktyce i nauczyć się tworzyć zaawansowane aplikacje ASP.NET Core, zapraszam do mojego szkolenia: Szkoła ASP.NET Core. W ramach szkolenia krok po kroku budujemy aplikacje w ASP.NET Core MVC i Web API, zwracając uwagę na dobre praktyki architektoniczne i porządek w kodzie.
