Clean Architecture & Design Patterns in Practice · Lekcja

Obsługa przekrojowych aspektów systemu

Zaimplementuj strategie rejestrowania zdarzeń, uwierzytelniania i autoryzacji bez naruszania Dependency Rule ani zanieczyszczania logiki podstawowej.

Lekcja 1 z 411 kroki

Obsługa przekrojowych aspektów systemu to bezpłatna lekcja Clean Architecture & Design Patterns in Practice na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Clean Architecture & Design Patterns in Practice, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Clean Architecture & Design Patterns in Practice zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

What are Cross-Cutting Concerns?

In software development, cross-cutting concerns are aspects of a system that affect many parts of the application but are not part of its core business logic. Think of them as system-wide services.

Logging: Recording events for debugging or auditing.
Authentication: Verifying a user's identity.
Authorization: Determining what an authenticated user can do.
Caching: Storing frequently accessed data for faster retrieval.
Transaction Management: Ensuring data consistency across multiple operations.

The Clean Architecture Dilemma

Clean Architecture emphasizes keeping your core business logic (Entities and Use Cases) independent of external frameworks and delivery mechanisms. This is enforced by the Dependency Rule: dependencies must only flow inwards.

The challenge arises because cross-cutting concerns often rely on specific external frameworks (e.g., a logging library, a security framework). How can we implement these concerns without violating the Dependency Rule and coupling our core logic to external details?

Logging Without Pollution

Let's take logging as an example. If a CreateUserUseCase directly calls a logging framework like Log4j or SLF4J, it creates a dependency on that specific framework.

CreateUserUseCase → Log4j

This violates the Dependency Rule because the inner layer (Use Case) would depend on an outer layer (Frameworks/Drivers). Our core logic should not care how logs are written, only that they need to be written.

Defining a Logging Port

To solve this, we introduce an interface in our inner (Use Case) layer. This interface, often called an Output Port, defines the contract for logging. The Use Case depends on this abstraction, not a concrete implementation.

package application.ports;

public interface ILogger {
    void info(String message);
    void error(String message, Throwable t);
}

Implementing the Logger Adapter

The actual logging framework implementation lives in an outer layer (e.g., Infrastructure). This concrete class acts as an Adapter, implementing our ILogger port and delegating to the specific logging library.

Notice how ConsoleLogger depends on ILogger (an inner layer abstraction), respecting the Dependency Rule.

package infrastructure.logging;

import application.ports.ILogger; // Depends on inner layer

public class ConsoleLogger implements ILogger {
    @Override
    public void info(String message) {
        System.out.println("[INFO] " + message);
    }

    @Override
    public void error(String message, Throwable t) {
        System.err.println("[ERROR] " + message + " - " + t.getMessage());
    }
}

Logger in a Use Case

Now, our CreateUserUseCase can depend on the ILogger interface. The concrete ConsoleLogger is injected at runtime, typically by a Dependency Injection (DI) container, but we'll do it manually here for clarity.

package application.usecases;

import application.ports.ILogger;
import infrastructure.logging.ConsoleLogger;

public class CreateUserUseCase {
    private final ILogger logger;

    public CreateUserUseCase(ILogger logger) {
        this.logger = logger;
    }

    public void execute(String username) {
        logger.info("Attempting to create user: " + username);
        // ... business logic to create user ...
        logger.info("User created successfully: " + username);
    }
}

public class Main {
    public static void main(String[] args) {
        // Manual Dependency Injection for demonstration
        ILogger consoleLogger = new ConsoleLogger();
        CreateUserUseCase useCase = new CreateUserUseCase(consoleLogger);
        useCase.execute("Alice");
    }
}

Handling Authentication

Authentication (verifying who a user is) should occur at the application's entry points, not within the core Use Cases. The Use Case should only receive already authenticated user information.

Middleware/Filters: In web applications, these intercept requests before they reach controllers.
Input Port Decorators: You can wrap a Use Case with a decorator that handles authentication before delegating to the actual Use Case.

This ensures the Use Case remains focused on business logic, free from security framework details.

Authorization with Policies

Authorization (what an authenticated user can do) is often more complex. While basic authorization can also be handled at the entry point, more granular checks might involve the Use Case.

Authorization Policies: Define separate objects or services that encapsulate authorization rules.
Interceptors/Aspects: Apply these policies around Use Case execution, checking permissions before the core logic runs.
The Use Case might depend on an IAuthorizationService interface (another Port) to query specific permissions.

DI for Cross-Cutting Concerns

The overarching principle for handling cross-cutting concerns in Clean Architecture is the Dependency Inversion Principle (DIP).

High-level modules (Use Cases) should not depend on low-level modules (frameworks).
Both should depend on abstractions (interfaces).
Abstractions are defined in the inner layers, and their concrete implementations reside in the outer layers, injected at runtime.

This keeps your core logic clean, testable, and independent of external technologies.

Applying Clean Concerns

Consider a ProcessOrderUseCase that needs to log critical steps. Which approach aligns best with Clean Architecture's Dependency Rule?

Odpowiedz w interaktywnej lekcji

Recap: Keeping Core Clean

We've explored strategies to handle cross-cutting concerns like logging, authentication, and authorization within Clean Architecture:

Abstract Concerns: Define interfaces (Ports) in inner layers for concerns like logging.
Implement Adapters: Provide concrete implementations of these interfaces in outer layers (Adapters).
Boundary Handling: Use middleware, decorators, or interceptors at application boundaries for authentication and authorization.
Dependency Inversion: This principle is crucial for ensuring your core business logic remains clean, independent, and free from external framework details.

Bezpłatny start

Ucz się Clean Architecture & Design Patterns in Practice dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 12
Lekcje: 48

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Obsługa przekrojowych aspektów systemu” jest bezpłatna?

Tak — pełny tekst „Obsługa przekrojowych aspektów systemu” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Clean Architecture & Design Patterns in Practice, przejdź na CoddyKit PRO. Kurs Clean Architecture & Design Patterns in Practice zawiera 4 lekcji w sumie.

Co nauczysz się w „Obsługa przekrojowych aspektów systemu”?

Zaimplementuj strategie rejestrowania zdarzeń, uwierzytelniania i autoryzacji bez naruszania Dependency Rule ani zanieczyszczania logiki podstawowej. Ćwiczysz Clean Architecture & Design Patterns in Practice z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Clean Architecture & Design Patterns in Practice?

Nie wymagamy żadnego doświadczenia. Clean Architecture & Design Patterns in Practice w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Obsługa przekrojowych aspektów systemu”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Clean Architecture & Design Patterns in Practice?

Tak. Każda lekcja Clean Architecture & Design Patterns in Practice zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Obsługa przekrojowych aspektów systemu
Clean Architecture sterowana zdarzeniami
Clean Architecture w mikrousługach
CQRS w ramach czystej architektury

← Powrót do Clean Architecture & Design Patterns in Practice