Clean Architecture im Frontend: So strukturierst du moderne Web-Apps

Die Entwicklung moderner Webanwendungen wird zunehmend komplexer, sobald mehrere Entwickler:innen an einem Projekt arbeiten oder die Codebasis über die Zeit wächst. Viele Teams kämpfen mit unübersichtlichem Code, der schwer zu warten ist und bei Änderungen zu unvorhersehbaren Fehlern führt. Eine Lösung für dieses Problem bietet die Clean Architecture – ein Architekturprinzip, das ursprünglich von Robert C. Martin geprägt wurde. Doch wie lässt sich dieses Konzept auf das Frontend übertragen, insbesondere in Projekten mit TypeScript und React?

Warum Clean Architecture auch im Frontend wichtig ist

Die Clean Architecture verfolgt das Ziel, Abhängigkeiten klar zu definieren und die Kernlogik der Anwendung von technischen Details zu trennen. Im Frontend bedeutet das konkret: Die Geschäftslogik sollte unabhängig von der Benutzeroberfläche, Frameworks oder externen APIs sein. Dadurch wird der Code nicht nur wartbarer, sondern auch testbarer und anpassungsfähiger an neue Anforderungen.

Ein häufiges Problem in Frontend-Projekten ist die enge Kopplung zwischen UI-Code und Geschäftslogik. Ändert sich etwa die API-Schnittstelle, müssen oft auch Komponenten im Frontend angepasst werden – selbst wenn die eigentliche Logik unverändert bleibt. Mit Clean Architecture lässt sich dieser Dominoeffekt vermeiden. Der Code wird in Schichten unterteilt, die sich gegenseitig nicht direkt beeinflussen:

• Domänen-Schicht (Entities): Enthält die grundlegenden Geschäftsregeln und Datenmodelle.
• Anwendungs-Schicht (Use Cases): Definiert die Anwendungsfälle und steuert den Datenfluss.
• Interface-Adapters (Presenter/Repository): Übersetzt zwischen den Anwendungsfällen und der Infrastruktur.
• Frameworks & Treiber (UI, API-Clients): Enthält Framework-spezifischen Code wie React-Komponenten oder HTTP-Clients.

Diese Trennung ermöglicht es, einzelne Komponenten auszutauschen – etwa ein Framework zu wechseln – ohne die gesamte Anwendung neu schreiben zu müssen.

Clean Architecture mit TypeScript und React umsetzen

Die Umsetzung von Clean Architecture im Frontend erfordert Disziplin, aber die Investition lohnt sich. Hier ist ein Schritt-für-Schritt-Ansatz für ein typisches React-Projekt mit TypeScript:

1. Domänen-Schicht definieren

Die Domänen-Schicht bildet das Herzstück der Anwendung. Hier werden die Geschäftsregeln und Datenmodelle definiert – unabhängig von jeder Technologie. Ein Beispiel für eine einfache Domäne könnte eine User-Entität sein:

// src/domain/entities/User.ts
export interface User {
  id: string;
  name: string;
  email: string;
}

export const validateUser = (user: User): boolean => {
  return user.email.includes('@');
};

Diese Datei enthält keine Abhängigkeiten zu React, Redux oder einer API. Sie definiert nur die grundlegenden Regeln, die für einen Benutzer gelten.

2. Anwendungsfälle (Use Cases) implementieren

Die Anwendungs-Schicht enthält die Geschäftslogik, die auf den Domänen-Entitäten arbeitet. Hier werden Use Cases als Klassen oder Funktionen definiert, die bestimmte Aktionen ausführen. Ein einfacher Use Case zum Abrufen von Benutzerdaten könnte so aussehen:

// src/application/useCases/fetchUser.ts
type FetchUserParams = { userId: string };

export const fetchUserUseCase = (
  userRepository: UserRepository,
  params: FetchUserParams
) => {
  const user = userRepository.findUser(params.userId);
  if (!user) throw new Error('Benutzer nicht gefunden');
  return user;
};

Der Use Case erwartet ein UserRepository als Abhängigkeit, das später implementiert wird. Diese lose Kopplung ermöglicht es, den Use Case unabhängig vom konkreten Datenzugriff zu testen.

3. Interface-Adapters für Datenzugriff und Präsentation

Die Interface-Adapters-Schicht fungiert als Brücke zwischen der Anwendungslogik und der Infrastruktur. Hier werden zwei wichtige Aufgaben erfüllt:

• Datenzugriff: Implementierung von Repositories, die Daten aus APIs, lokalem Speicher oder anderen Quellen abrufen.
• Präsentation: Übersetzen von Anwendungsdaten in ein Format, das die UI-Komponenten verstehen.

Ein Beispiel für ein UserRepository mit einem HTTP-Client:

// src/infrastructure/repositories/UserRepository.ts
import { User } from '../../domain/entities/User';

interface HttpClient {
  get: (url: string) => Promise<unknown>;
}

export class UserRepositoryImpl implements UserRepository {
  constructor(private httpClient: HttpClient) {}

  async findUser(userId: string): Promise<User> {
    const data = await this.httpClient.get(`/api/users/${userId}`);
    return data as User;
  }
}

Um die React-Komponenten zu entkoppeln, wird ein Presenter verwendet, der die Anwendungsdaten in ein UI-freundliches Format übersetzt:

// src/interfaceAdapters/presenters/UserPresenter.ts
import { User } from '../../domain/entities/User';

export const formatUserForUI = (user: User) => ({
  id: user.id,
  displayName: user.name,
  email: user.email,
});

4. React-Komponenten als reine UI-Elemente

Die React-Komponenten sollten so einfach wie möglich gehalten werden. Sie erhalten ihre Daten von den Presentern und lösen keine Geschäftslogik aus. Ein Beispiel für eine UserProfile-Komponente:

// src/ui/components/UserProfile.tsx
import { User } from '../domain/entities/User';

type UserProfileProps = {
  user: User;
};

export const UserProfile = ({ user }: UserProfileProps) => {
  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
};

Die Komponente kennt weder die Herkunft der Daten noch die Geschäftslogik – sie stellt sie lediglich dar. Diese Trennung macht den Code nicht nur wartbarer, sondern auch einfacher zu testen.

Vorteile und Herausforderungen

Die Einführung von Clean Architecture im Frontend bringt mehrere Vorteile mit sich:

• Einfachere Wartung: Änderungen in einem Bereich erfordern keine Anpassungen in anderen Schichten.
• Bessere Testbarkeit: Geschäftslogik lässt sich unabhängig von Frameworks oder APIs testen.
• Flexibilität: Ein Framework-Wechsel (z. B. von React zu Vue) ist mit geringem Aufwand möglich.
• Klare Verantwortlichkeiten: Jede Schicht hat eine definierte Aufgabe, was die Codequalität erhöht.

Allerdings gibt es auch Herausforderungen:

• Steilere Lernkurve: Entwickler:innen müssen sich mit neuen Konzepten wie Dependency Injection vertraut machen.
• Boilerplate-Code: Die Trennung in Schichten kann zu mehr Dateien und mehr Code führen.
• Initialer Aufwand: Der Aufbau eines solchen Systems erfordert Zeit und Planung.

Fazit: Clean Architecture als Investition in die Zukunft

Clean Architecture ist kein Allheilmittel, aber eine bewährte Methode, um Frontend-Projekte langfristig wartbar und skalierbar zu halten. Besonders in Teams mit hoher Fluktuation oder komplexen Anforderungen lohnt sich der initiale Aufwand. Die klare Trennung von Verantwortlichkeiten reduziert technische Schulden und ermöglicht es, schneller auf neue Anforderungen zu reagieren.

Für Entwickler:innen, die bereits mit Domain-Driven Design oder SOLID-Prinzipien vertraut sind, ist der Einstieg in Clean Architecture im Frontend leichter. Wer noch keine Erfahrung mit diesen Konzepten hat, sollte mit kleineren Projekten beginnen, um die Prinzipien zu verinnerlichen. Letztlich ist Clean Architecture eine Investition in die Zukunftsfähigkeit des Codes – und damit in die Effizienz des gesamten Teams.