Clean Architecture & Design Patterns in Practice · Lekcja

Funkcje kondycji architektury i testy granic

Nauczą się Państwo chronić granice architektury w czasie za pomocą automatycznych funkcji kondycji oraz testów kierunku zależności.

Lekcja 4 z 413 kroki

Funkcje kondycji architektury i testy granic to bezpłatna lekcja Clean Architecture & Design Patterns in Practice na CoddyKit. To lekcja 4 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.

Architecture Erodes Silently

A clean design tends to decay. Under deadline pressure, someone imports the database into an entity, or a use case reaches into the web layer.

Code review alone misses these. We need automated guards.

What Is a Fitness Function?

An architectural fitness function is an automated test that asserts a structural property of the system.

Just as unit tests guard behavior, fitness functions guard architecture — for example, the direction of dependencies.

The Rule We Want to Enforce

In Clean Architecture, dependencies point inward:

  • Entities depend on nothing.
  • Use cases depend only on entities.
  • Frameworks depend inward, never the reverse.

A fitness function can fail the build if this is broken.

Expressing It as a Test

Tools like ArchUnit let you encode the rule directly.

ArchRule rule = classes()
    .that().resideInAPackage("..domain..")
    .should().onlyDependOnClassesThat()
    .resideInAnyPackage("..domain..", "java..");

Forbidding Forbidden Imports

You can also assert that the core never touches infrastructure.

noClasses()
    .that().resideInAPackage("..usecase..")
    .should().dependOnClassesThat()
    .resideInAPackage("..web..");

Boundary Contract Tests

Beyond dependency direction, test that adapters honor their port contracts.

Run the same suite against every implementation of a gateway so a new adapter cannot silently break the boundary.

A Simple Home-Grown Check

Even without a library you can scan for violations programmatically.

public class Main {
  public static void main(String[] a){
    String[] domainImports = {"java.util.List", "domain.Order"};
    boolean clean = true;
    for (String imp : domainImports) {
      if (imp.startsWith("web.") || imp.startsWith("db.")) { clean = false; }
    }
    System.out.println("Domain layer clean: " + clean);
  }
}

Running Them in CI

Fitness functions belong in the continuous integration pipeline.

When a pull request breaks a boundary, the build goes red immediately — long before the violation spreads through the codebase.

Choosing the Right Functions

  • Layer dependency direction.
  • No framework imports in the core.
  • Naming and package conventions.
  • Cyclic-dependency detection.

Start with the few rules that matter most for your design.

Evolving the Rules

Fitness functions are living. As the architecture intentionally evolves, update the rules to match the new intent.

A failing fitness function is a prompt to decide: fix the code, or consciously change the rule.

Balancing Strictness

Too many brittle rules cause friction and get disabled. Too few let decay creep in.

Aim for a small set of high-value, stable rules that protect the boundaries you care most about.

Quick Check

Test your understanding of fitness functions.

Recap

You learned to defend boundaries over time.

  • Fitness functions automate architectural rules.
  • Enforce inward dependency direction and a framework-free core.
  • Run them in CI and evolve them deliberately as the design changes.
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

Często zadawane pytania

Czy lekcja „Funkcje kondycji architektury i testy granic” jest bezpłatna?

Tak — pełny tekst „Funkcje kondycji architektury i testy granic” 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 „Funkcje kondycji architektury i testy granic”?

Nauczą się Państwo chronić granice architektury w czasie za pomocą automatycznych funkcji kondycji oraz testów kierunku zależności. Ć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 4 z 4.

Ile czasu zajmuje lekcja „Funkcje kondycji architektury i testy granic”?

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

  1. Warstwowa strategia testowania
  2. Aspekty wdrażania Clean Architecture
  3. Rozwijanie i utrzymywanie czystych systemów
  4. Funkcje kondycji architektury i testy granic
← Powrót do Clean Architecture & Design Patterns in Practice