Refaktoring do Clean Architecture w C# – Podział na Warstwy

🔑 Spis treści

1. Czym jest Clean Architecture?
2. Dlaczego refaktoring jest potrzebny?
3. Jak podzielić kod na warstwy w C#?
   • Core (Domain
   • Application
   • Infrastructure
   • UI
4. Zalety Clean Architecture
5. Refaktoring w praktyce – przykład w C#
6. Podsumowanie i kolejne kroki

---

🏛 Czym jest Clean Architecture?

CRefaktoring do Clean Architecture w C# – Podział na Warstwy opiera się na wzorcu zaproponowanym przez Roberta C. Martina (Uncle Bob). Jego główna zasada brzmi: wewnętrzne warstwy nie mogą zależeć od zewnętrznych. Dzięki temu kod jest bardziej przejrzysty, łatwiejszy w testowaniu i skalowalny.

Najważniejsze elementy:

• Domena (Core) – logika biznesowa, niezależna od technologii.
• Application – orkiestracja i scenariusze użycia.
• Infrastructure – szczegóły techniczne (np. pliki JSON, baza SQL).
• UI – prezentacja (np. konsola, WPF, ASP.NET Core).

👉 Dzięki temu możemy testować, rozwijać i skalować projekt bez przepisywania wszystkiego od nowa.

---

🚨 Dlaczego refaktoring jest potrzebny?

Problemy monolitycznego kodu:

• Wszystko w jednym miejscu = chaos.
• Trudności w testowaniu („Jak przetestować logikę walki bez konsoli?”).
• Brak skalowalności – dodanie bazy danych = przepisywanie całego kodu.
• Jedna zmiana może zepsuć wszystko.

✅ Rozwiązanie: podział na warstwy w Clean Architecture.

---

🔨 Jak podzielić kod na warstwy w C#?

1. Core (Domain / Business Logic)

Projekt typu Class Library – DevHobby.Code.RPG.Core

👉 Co tu wrzucamy?

• Encje domenowe: Postac, Bohater, Potwor, Wojownik, Mag…
• Interfejsy (np. IPostacFactory).
• Reguły gry (np. logika walki).

💡 Core nie wie, czy dane pochodzą z JSON, TXT czy bazy SQL – to czysta logika.

---

2. Application

Projekt typu Class Library – DevHobby.Code.RPG.Application

👉 Zadania:

• Scenariusze gry („Rozpocznij nową grę”, „Załaduj postacie z pliku”).
• Orkiestracja logiki Core z usługami Infrastructure.
• Usługi wyższego poziomu (np. GameService).

💡 Application to mistrz gry – prowadzi rozgrywkę, ale nie zagląda do szczegółów technicznych.

---

3. Infrastructure

Projekt typu Class Library – DevHobby.Code.RPG.Infrastructure

👉 Tu trafiają szczegóły techniczne:

• JsonPostacRepository – odczyt z pliku JSON.
• TxtPostacRepository – odczyt z pliku TXT.
• PostacFactory – implementacja IPostacFactory.

💡 Infrastructure to „kuchnia” – Core zamawia pizzę, a Infrastructure decyduje, skąd weźmie składniki.

---

4. UI (ConsoleApp)

Projekt typu ConsoleApp – DevHobby.Code.RPG.ConsoleApp

👉 Zadania UI:

• Wczytanie danych.
• Uruchomienie gry.
• Wyświetlenie wyników.

💡 UI to tylko interfejs – dziś konsola, jutro API lub aplikacja desktopowa.

---

✅ Zalety Clean Architecture

• Separation of Concerns – każda warstwa ma jedną odpowiedzialność.
• Testability – łatwo testować każdą warstwę osobno.
• Maintainability – szybkie wprowadzanie zmian.
• Scalability – możliwość łatwego dodawania nowych funkcji.

---

👨‍💻 Refaktoring w praktyce – przykład w C#

// Core: Interfejs
public interface IPostacFactory
{
    Postac Create(string type, string name);
}

// Infrastructure: Implementacja
public class PostacFactory : IPostacFactory
{
    public Postac Create(string type, string name)
    {
        return type switch
        {
            "Wojownik" => new Wojownik(name),
            "Lucznik" => new Lucznik(name),
            "Mag" => new Mag(name),
            _ => throw new ArgumentException("Nieznany typ postaci")
        };
    }
}

🎯 Podsumowanie i kolejne kroki

W tym wpisie podzieliliśmy projekt na cztery warstwy i zbudowaliśmy fundament Clean Architecture.
To dopiero pierwszy krok – w kolejnych etapach zajmiemy się:

• Repository Pattern,
• Service Layer,
• Dependency Injection,
• i finalnym polish projektu RPG.

👉 Zobacz też: Tworzenie klas w C# – kompletny poradnik

Podobał Ci się ten artykuł?

• 🔔 Zapisz się do newslettera, aby nie przegapić kolejnych części.
• 💬 Napisz w komentarzu, czy Twój kod przypomina spaghetti – pogadamy!