ViewModel Aggregation – Das ViewModel ist kein Durchreicher

Ein ViewModel ist nicht der höfliche Praktikant, der API-Daten entgegennimmt und sie wortlos an die Komponente weiterreicht.

Ein ViewModel ist eine Entscheidung.

Es entscheidet, was eine Oberfläche wirklich braucht.
Es entscheidet, welche Daten zusammengehören.
Es entscheidet, welche Zustände sichtbar sind.
Und es entscheidet, welche Komplexität nicht in Templates, Komponenten oder Backend-DTOs auslaufen darf.

Das klingt erstmal nach Architekturlyrik.

Ist es aber nicht.

Es ist einer der Unterschiede zwischen einem Frontend, das nach zwei Jahren noch verständlich ist, und einem Frontend, in dem jede Komponente heimlich ein kleines Integrationsprojekt geworden ist.

Der Mythos: Das Backend liefert doch schon alles

Der Mythos klingt meistens ungefähr so:

„Wir brauchen kein extra ViewModel. Die API liefert doch schon alle Daten.“

Das ist einer dieser Sätze, die auf den ersten Blick effizient wirken.

Keine zusätzliche Schicht.
Keine Transformation.
Keine Mapper.
Weniger Code.

Sehr angenehm.

Bis man merkt, dass „alle Daten“ nicht dasselbe ist wie „die richtigen Informationen für diesen Screen“.

Ein API-DTO beantwortet meistens die Frage:

Was kann ein System über eine Ressource liefern?

Ein ViewModel beantwortet eine andere Frage:

Was muss diese konkrete Oberfläche in dieser konkreten Situation zeigen, erlauben oder verhindern?

Das ist nicht dasselbe.

Und es wird auch nicht dasselbe, nur weil beide Objekte zufällig ähnliche Feldnamen haben.

Ein DTO ist kein UI-Vertrag

DTOs entstehen oft aus Backend-Sicht.

Das ist auch völlig legitim.

Sie transportieren Daten über eine Grenze. Sie bilden Datenbanknähe, API-Konventionen, Integrationsanforderungen, Legacy-Strukturen oder externe Systeme ab. Manchmal sogar alles gleichzeitig, weil irgendjemand irgendwann „nur kurz“ ein Feld ergänzt hat.

Das DTO kann technisch korrekt sein.

Und trotzdem als UI-Modell ungeeignet.

Denn eine Oberfläche braucht nicht einfach Daten. Sie braucht Bedeutung.

Zum Beispiel nicht nur:

{
  status: 'ACTIVE',
  archivedAt: null,
  permissions: ['EDIT', 'DELETE'],
  lockedByUserId: 'u-123',
  updatedAt: '2026-06-22T09:15:00Z'
}

Sondern eher:

{
  title: 'Projekt Alpha',
  statusLabel: 'Aktiv',
  canEdit: true,
  canDelete: false,
  warning: 'Wird gerade von Anna bearbeitet',
  primaryAction: 'Bearbeiten',
  isStale: false
}

Das zweite Objekt ist nicht „dümmer“.

Es ist näher an der Oberfläche.

Und damit oft näher an der Wahrheit, die der Benutzer tatsächlich erlebt.

Durchreichen ist keine Architektur. Es ist Aufgeben mit Autocomplete.

Natürlich kann man DTOs direkt in Komponenten verwenden.

Man kann auch Geschäftsregeln ins Template schreiben. Man kann Ladezustände mit drei Booleans modellieren. Man kann Berechtigungen in fünf Komponenten duplizieren. Man kann customer.addresses?.[0]?.city direkt im HTML rendern und hoffen, dass es schon gut geht.

Man kann vieles.

Die Frage ist nur, ob man es Architektur nennen sollte.

Wenn eine Komponente direkt mit Backend-DTOs arbeitet, wird sie schnell zu einer Mischung aus:

• Renderer
• Mapper
• Berechtigungsprüfer
• Zustandsautomat
• Fallback-Logik
• Integrationsadapter
• Fehlermeldungsfabrik
• und nebenbei noch UI-Komponente

Das ist dann keine Komponente mehr.

Das ist ein kleiner Unfall mit Angular-Dekorator.

Das Problem beginnt selten groß

Am Anfang sieht das harmlos aus.

Ein Feld aus der API wird angezeigt.

{{ project.name }}

Dann kommt ein Status dazu.

@if (project.status === 'ACTIVE') { Aktiv }

Dann eine Berechtigung.

@if (project.permissions.includes('EDIT')) {
<button>Bearbeiten</button>
}

Dann eine Sonderregel.

@if (project.status === 'ACTIVE' && !project.archivedAt && project.permissions.includes('EDIT')) {
<button>Bearbeiten</button>
}

Dann ein Locking-Fall.

Dann ein Feature-Flag.

Dann ein Spezialfall für migrierte Daten.

Dann ein temporärer Workaround, der sieben Monate bleibt.

Und irgendwann steht im Template mehr Fachlogik als Markup.

Natürlich nennt es dann niemand Fachlogik.

Man nennt es „nur Anzeige“.

Das ist die kleine Schwester von „ist doch nur UI“.

ViewModel Aggregation heißt: Oberfläche ernst nehmen

ViewModel Aggregation bedeutet nicht, ein DTO umzubenennen.

Es bedeutet, aus mehreren Quellen, Regeln und Zuständen ein Modell zu formen, das exakt zu einem UI-Kontext passt.

Das kann beinhalten:

• Daten aus mehreren API-Antworten zusammenführen
• technische Statuswerte in verständliche UI-Zustände übersetzen
• Berechtigungen in sichtbare Aktionen transformieren
• Lade-, Fehler- und Leerzustände modellieren
• Prioritäten für Hinweise, Warnungen und Call-to-Actions festlegen
• Formatierungen vorbereiten
• Fallbacks zentral behandeln
• Sonderfälle bewusst kapseln

Kurz gesagt:

Das ViewModel ist der Ort, an dem Rohdaten zu einer darstellbaren Entscheidung werden.

Nicht im Template. Nicht verteilt über fünf Komponenten. Nicht als get canEdit() mit halbem Domänenmodell im Component-Code. Und bitte auch nicht als „kleine Pipe“, die nebenbei ein Geschäftsregel-Orakel spielt.

Ein Screen ist oft mehr als eine Ressource

Viele Frontend-Probleme entstehen, weil Teams so tun, als würde ein Screen immer genau einer Backend-Ressource entsprechen.

Tut er nicht.

Ein Dashboard zeigt nicht „ein DTO“. Eine Detailseite zeigt nicht nur „einen Datensatz“. Eine Liste zeigt nicht nur „eine Collection“. Ein Formular zeigt nicht nur „ein Entity“.

Ein Screen zeigt einen Arbeitskontext.

Und dieser Arbeitskontext besteht oft aus mehreren Dingen:

Projekt
+ Mitglieder
+ Rollen
+ letzte Aktivität
+ Berechtigungen
+ offene Aufgaben
+ Systemhinweise
+ Ladezustand
+ Fehlerzustand
+ UI-Auswahl
+ Feature-Konfiguration

Wenn es dafür kein ViewModel gibt, wird die Komponente automatisch zur Aggregationsschicht.

Nicht weil jemand das entschieden hat.

Sondern weil niemand etwas anderes entschieden hat.

Das ist der gefährlichste Architekturmodus: Zufallsarchitektur durch Weglassen.

Das ViewModel ist kein Backend-Modell in hübsch

Ein häufiger Fehler ist, ViewModels nur als leicht umbenannte DTOs zu bauen.

Aus ProjectDto wird dann ProjectViewModel.

Aber innen sieht es immer noch so aus:

type ProjectViewModel = {
  id: string;
  name: string;
  status: string;
  archivedAt: string | null;
  permissions: string[];
  members: MemberDto[];
};

Das ist kein ViewModel.

Das ist ein DTO mit Bart angeklebt.

Ein echtes ViewModel ist nicht daran interessiert, die Backend-Struktur besonders treu abzubilden. Es ist daran interessiert, der Oberfläche ein stabiles, verständliches Modell zu geben.

Zum Beispiel:

type ProjectHeaderViewModel = {
  title: string;
  subtitle: string;
  status: {
    label: string;
    tone: 'neutral' | 'success' | 'warning' | 'danger';
  };
  actions: {
    edit: ViewAction;
    archive: ViewAction;
  };
  notice?: {
    message: string;
    tone: 'info' | 'warning' | 'danger';
  };
};

Das ist absichtlich anders.

Denn die UI braucht keine Rohberechtigungsliste.

Sie braucht eine Entscheidung:

Darf der Benutzer bearbeiten? Soll der Button sichtbar sein? Ist er deaktiviert? Warum? Welche Meldung wird angezeigt?

Diese Entscheidung gehört nicht in drei Templates und zwei Komponentenmethoden verteilt.

Sie gehört in ein ViewModel.

„Aber dann duplizieren wir doch Logik“

Ja.

Vielleicht.

Und manchmal ist das genau richtig.

Nicht jede Logik, die ähnlich aussieht, ist dieselbe Logik.

Backend-Logik schützt Systemzustand. Frontend-Logik schützt Benutzerführung.

Das Backend entscheidet verbindlich, ob eine Aktion erlaubt ist. Das Frontend entscheidet, wie diese Möglichkeit verständlich dargestellt wird.

Das Backend muss trotzdem validieren. Immer.

Aber daraus folgt nicht, dass das Frontend dumm bleiben muss.

Ein Frontend, das keine eigenen UI-Entscheidungen trifft, produziert keine Einfachheit. Es produziert schlechte Benutzerführung mit gutem Gewissen.

Der Klassiker:

„Der Button kann ruhig sichtbar bleiben. Wenn es nicht erlaubt ist, gibt die API halt 403 zurück.“

Technisch korrekt.

Produktseitig oft eine Zumutung.

Architektonisch ein Hinweis darauf, dass jemand „Single Source of Truth“ mit „Single Source of Frust“ verwechselt hat.

Wo ViewModel Aggregation hingehört

Die schlechteste Antwort lautet meistens: „in die Komponente“.

Nicht weil Komponenten nichts dürfen.

Sondern weil Komponenten dafür sehr schnell der falsche Ort werden.

Eine Komponente sollte rendern, Events ausdrücken und UI-Struktur halten. Sie sollte nicht nebenbei aus sechs Quellen einen fachlichen Arbeitszustand komponieren.

Bessere Orte sind je nach Architektur:

• Facades
• Stores
• Signal Stores
• Query-/Presenter-Schichten
• Feature-spezifische Adapter
• Use-Case-nahe Presentation Services

Der Name ist weniger wichtig als die Verantwortung.

Wichtig ist:

Das ViewModel entsteht an einer klaren Stelle. Die Regeln sind testbar. Die Komponente konsumiert ein fertiges Modell. Der Screen muss nicht wissen, aus welchen technischen Quellen sein Zustand zusammengebaut wurde.

In Angular mit Signals kann das zum Beispiel so aussehen:

readonly vm = computed<ProjectHeaderViewModel>(() => {
  const project = this.project();
  const permissions = this.permissions();
  const lock = this.lock();

  if (!project) {
    return {
      title: 'Projekt wird geladen',
      subtitle: '',
      status: { label: 'Laden', tone: 'neutral' },
      actions: {
        edit: { visible: false },
        archive: { visible: false },
      },
    };
  }

  const canEdit = permissions.includes('PROJECT_EDIT') && !lock.isLocked;

  return {
    title: project.name,
    subtitle: `Zuletzt geändert am ${formatDate(project.updatedAt)}`,
    status: mapProjectStatus(project.status),
    actions: {
      edit: {
        visible: true,
        enabled: canEdit,
        label: 'Bearbeiten',
        disabledReason: canEdit ? undefined : 'Projekt ist aktuell gesperrt',
      },
      archive: {
        visible: permissions.includes('PROJECT_ARCHIVE'),
        enabled: project.status !== 'ARCHIVED',
        label: 'Archivieren',
      },
    },
    notice: lock.isLocked
      ? {
          tone: 'warning',
          message: `Wird gerade von ${lock.userName} bearbeitet`,
        }
      : undefined,
  };
});

Das ist mehr Code als direktes Durchreichen.

Ja.

Aber es ist Code an der richtigen Stelle.

Und das ist ein ziemlich unterschätztes Qualitätsmerkmal.

Gute ViewModels machen Templates langweilig

Ein gutes Template ist nicht unbedingt kurz.

Aber es sollte langweilig sein.

Langweilig im besten Sinn.

Es sollte nicht dauernd erklären müssen, warum ein Button sichtbar ist. Es sollte keine Statuscodes interpretieren. Es sollte keine API-Strukturen kennen. Es sollte keine Berechtigungslogik nachbauen. Es sollte keine Sonderfälle aus Legacy-Daten erkennen.

Es sollte ein ViewModel darstellen.

<h1>{{ vm.title }}</h1>
<p>{{ vm.subtitle }}</p>

<app-status-badge [label]="vm.status.label" [tone]="vm.status.tone" />

@if (vm.notice) {
<app-notice [tone]="vm.notice.tone" [message]="vm.notice.message" />
} @if (vm.actions.edit.visible) {
<button [disabled]="!vm.actions.edit.enabled" [title]="vm.actions.edit.disabledReason ?? ''">{{ vm.actions.edit.label }}</button>
}

Das ist nicht spektakulär.

Genau das ist der Punkt.

Spektakel gehört in Architekturentscheidungen, nicht in Templates.

Aggregation reduziert Kopplung

Direktes Durchreichen koppelt die UI an die API.

Nicht nur technisch.

Auch gedanklich.

Wenn das Template project.status === 'ACTIVE' kennt, kennt es Backend-Statuswerte. Wenn die Komponente permissions.includes('EDIT') prüft, kennt sie Autorisierungskonventionen. Wenn die UI archivedAt === null interpretiert, kennt sie Speicherlogik. Wenn fünf Komponenten dieselbe Kombination prüfen, kennt bald niemand mehr die Wahrheit.

Dann wird jede Backend-Änderung zur UI-Schnitzeljagd.

Wo wurde dieser Status verwendet? Welche Komponente prüft das Flag? Welche Pipe formatiert diesen Sonderfall? Warum zeigt die Liste etwas anderes als die Detailseite? Warum ist der Button hier deaktiviert und dort unsichtbar?

Und irgendwann macht jemand ein Ticket auf:

„Anzeige inkonsistent bei archivierten Projekten mit Locking.“

Ein Satz, der meistens bedeutet:

„Wir haben nie entschieden, wo diese Entscheidung lebt.“

ViewModel Aggregation schafft eine Grenze.

Nicht aus Prinzip.

Sondern damit Änderungen nicht überall gleichzeitig einschlagen.

Aggregation ist besonders wichtig bei Micro Frontends und SCS

In einfachen Anwendungen kann man viele Fehler eine Weile verstecken.

In größeren Systemen nicht.

Wenn mehrere Teams, Self-Contained Systems oder Micro Frontends an einer Produktlandschaft arbeiten, wird ViewModel Aggregation noch wichtiger.

Denn dann gibt es nicht nur ein Backend und eine UI.

Es gibt mehrere fachliche Kontexte.

Ein User im Admin-Bereich ist nicht dasselbe wie ein User im Dashboard. Ein Task in der Planung ist nicht dasselbe wie ein Task im Activity Stream. Ein Project in der Verwaltung ist nicht dasselbe wie ein Project in einer Auswertung.

Gleiche Datenbasis heißt nicht gleiche Sicht.

Jeder UI-Kontext braucht sein eigenes Modell.

Sonst entsteht ein sehr beliebtes Architekturmonster:

Das universelle Shared Model.

Es kann alles. Es wird überall verwendet. Niemand darf es ändern. Alle hassen es. Aber es heißt „Wiederverwendung“, also fühlt es sich professionell an.

Ein ViewModel darf bewusst redundant sein

Viele Teams haben Angst vor Redundanz.

Verständlich.

Niemand will dieselbe Logik zehnmal pflegen.

Aber aus Angst vor Redundanz entstehen oft Modelle, die für alles ein bisschen passen und für nichts wirklich gut sind.

Ein ViewModel darf bewusst redundant sein, wenn es dadurch einen UI-Kontext klarer macht.

Zum Beispiel:

type TaskListItemViewModel = {
  title: string;
  assigneeLabel: string;
  dueDateLabel: string;
  isOverdue: boolean;
  rowTone: 'normal' | 'warning' | 'danger';
};

Ja, isOverdue könnte man aus dueDate berechnen. Ja, dueDateLabel könnte man im Template formatieren. Ja, rowTone könnte man aus Status, Datum und Priorität ableiten.

Kann man.

Muss man aber nicht an der Stelle tun, die am schlechtesten dafür geeignet ist.

Redundanz im ViewModel ist nicht automatisch schlecht.

Schlecht ist unkontrollierte Redundanz ohne klare Verantwortung.

Ein vorberechnetes Feld in einem ViewModel kann sehr sinnvoll sein, wenn es eine UI-Entscheidung ausdrückt.

ViewModels sind testbare Architektur

Ein unterschätzter Vorteil von ViewModels:

Man kann sie hervorragend testen.

Nicht mit riesigen End-to-End-Tests. Nicht mit Screenshot-Vergleichen. Nicht mit „klick mal durch und schau, ob es komisch aussieht“.

Sondern mit kleinen, gezielten Tests auf Entscheidungslogik.

Beispiele:

Wenn ein Projekt gesperrt ist,
dann ist die Bearbeiten-Aktion sichtbar,
aber deaktiviert,
und der Sperrhinweis wird angezeigt.

Oder:

Wenn ein Task überfällig und kritisch ist,
dann erhält die Zeile den Danger-Tone
und das Fälligkeitsdatum wird als Warnhinweis dargestellt.

Das sind fachliche UI-Regeln.

Sie gehören nicht ausschließlich in manuelle Tests. Und sie gehören nicht versteckt in Templates.

Wenn ViewModel Aggregation sauber gebaut ist, kann man diese Regeln isoliert prüfen.

Das ist kein Testfetisch.

Das ist eine günstige Versicherung gegen „Warum sieht das hier plötzlich anders aus?“.

Warnsignale für fehlende ViewModel Aggregation

Man erkennt fehlende ViewModel Aggregation selten an einem großen Architekturdiagramm.

Man erkennt sie an Sätzen im Alltag.

Zum Beispiel:

„Das Feld kommt halt so aus der API.“

„Die Komponente muss nur kurz prüfen, ob der Status aktiv ist.“

„Das steht auch noch mal in der Liste, aber leicht anders.“

„Der Button ist hier disabled, dort hidden, keine Ahnung warum.“

„Das Backend soll einfach noch ein Flag liefern.“

„Wir brauchen komplette Response, weil irgendwo noch was gebraucht wird.“

„Das Template ist etwas unübersichtlich, aber funktioniert.“

Das sind keine kleinen Schönheitsfehler.

Das sind Hinweise darauf, dass UI-Bedeutung nicht modelliert wurde.

Und wenn Bedeutung nicht modelliert wird, verteilt sie sich.

In Komponenten. In Templates. In Pipes. In Helpern. In Copy-Paste. In Tickets. In Köpfen.

Vor allem in Köpfen.

Und Köpfe skalieren in Softwareprojekten traditionell eher mäßig.

Nicht jedes Feld braucht ein ViewModel-Theater

Natürlich muss man nicht für jedes Label eine eigene Architekturkathedrale bauen.

Wenn ein Screen wirklich nur ein paar Felder anzeigt, darf das Modell einfach sein.

Architektur bedeutet nicht, aus jedem name ein DisplayNameRenderingContextViewModel zu machen.

Bitte nicht.

Der Punkt ist nicht maximale Schichtung.

Der Punkt ist bewusste Verantwortung.

Je mehr ein Screen entscheidet, desto eher braucht er ein explizites ViewModel.

Faustregel:

Wenn Daten nur angezeigt werden, reicht oft ein einfaches Modell. Wenn Daten interpretiert werden, braucht es eine klare Stelle für diese Interpretation. Wenn mehrere Quellen, Regeln, Rechte oder Zustände kombiniert werden, ist ViewModel Aggregation kein Luxus mehr.

Dann ist sie Brandschutz.

Gute ViewModel Aggregation stellt bessere Fragen

Statt zu fragen:

„Welche Daten liefert die API?“

sollte man früher fragen:

„Welche Entscheidung muss der Screen treffen?“

Das verändert die Diskussion.

Plötzlich geht es nicht mehr nur um Felder.

Sondern um Verhalten.

Welche Aktionen gibt es? Wann sind sie sichtbar? Wann sind sie deaktiviert? Welche Zustände schließen sich aus? Was sieht der Benutzer bei leeren Daten? Was passiert bei Teilfehlern? Welche Information ist primär? Welche ist nur Kontext? Welche Sonderfälle müssen erklärt werden?

Das sind Produkt-, Architektur- und Teamfragen.

Nicht nur Frontend-Details.

Und genau deshalb ist ViewModel Aggregation kein kosmetischer Mapper am Rand.

Sie ist Teil des Designs.

Eine bessere Alternative: Screen-spezifische ViewModels

Eine brauchbare Alternative zum Durchreichen sieht ungefähr so aus:

API DTOs / externe Modelle
        ↓
Feature Adapter / Mapper
        ↓
Store / Facade / Query Layer
        ↓
Screen-spezifisches ViewModel
        ↓
Komponente / Template

Wichtig ist dabei nicht, dass jedes Projekt exakt diese Begriffe verwendet.

Wichtig ist die Richtung:

Rohdaten werden nicht nach unten durchgereicht, bis sie irgendwo im Template explodieren. Sie werden früh genug in ein UI-Modell übersetzt, das der Screen versteht.

Ein gutes ViewModel ist dabei:

• spezifisch genug für den Screen
• stabil gegenüber API-Details
• verständlich für Entwickler
• testbar
• explizit in seinen UI-Entscheidungen
• klein genug, um nicht selbst zum Universalmonster zu werden

Management-Perspektive: Warum das nicht nur Entwickler-Ästhetik ist

ViewModel Aggregation klingt nach internem Codegeschmack.

Ist es aber nicht.

Fehlende Aggregation erzeugt Kosten, die man später sehr real spürt:

Inkonsistente Oberflächen. Langsamere Änderungen. Mehr Regressionen. Mehr Abstimmungsaufwand. Mehr „Warum ist das hier anders?“. Mehr Angst vor Refactoring. Mehr Tickets für Symptome.

Das Problem ist nicht, dass Entwickler gerne schöne Modelle malen.

Das Problem ist, dass unmodellierte UI-Entscheidungen trotzdem existieren.

Sie sind dann nur schwerer zu finden.

Für Entscheider bedeutet das:

Ein Frontend, das DTOs direkt durchreicht, wirkt kurzfristig schneller.

Langfristig kauft man sich damit eine Oberfläche, deren Verhalten aus verstreuten Bedingungen besteht.

Das ist keine Geschwindigkeit.

Das ist technischer Kredit mit variabler Verzinsung.

Und die Zinsen steigen meistens genau dann, wenn das Produkt erfolgreicher wird.

Team-Perspektive: ViewModels schaffen gemeinsame Sprache

Gute ViewModels helfen nicht nur dem Code.

Sie helfen dem Team.

Wenn es ein ProjectHeaderViewModel, ein TaskListItemViewModel oder ein DashboardActivityViewModel gibt, kann man darüber sprechen.

Nicht abstrakt über „das DTO“. Nicht diffus über „die Daten“. Sondern konkret über die Sicht.

Was braucht diese Karte? Was entscheidet diese Liste? Welche Zustände hat dieser Header? Welche Aktionen sind erlaubt? Welche Hinweise haben Vorrang?

Das ist gemeinsame Sprache auf UI-Ebene.

Und gemeinsame Sprache ist in Frontend-Architektur bitter nötig, weil Frontends heute nicht mehr nur Oberflächen sind.

Sie sind Arbeitsplätze.

Sie sind Prozessführung.

Sie sind fachliche Interaktion.

Sie sind oft der einzige Teil des Systems, den Benutzer überhaupt sehen.

Da darf das Modell ruhig etwas mehr können, als JSON weiterzureichen.

Der eigentliche Punkt

ViewModel Aggregation ist keine Frage von Schönheit.

Es ist eine Frage von Verantwortung.

Irgendwo muss entschieden werden, wie Rohdaten zu sichtbarer Bedeutung werden.

Die einzige echte Wahl ist:

Entscheiden wir das bewusst an einer klaren Stelle?

Oder lassen wir es über Komponenten, Templates, Pipes und Zufälle verteilt entstehen?

Das erste nennt man Architektur.

Das zweite nennt man später Legacy.

Merksatz

Ein ViewModel beschreibt nicht, was das Backend geliefert hat.

Es beschreibt, was die Oberfläche verstanden haben muss.

Wer ViewModels nur durchreicht, verschiebt Entscheidungen in Templates, Komponenten und Köpfe.

Und Köpfe sind die teuerste Laufzeitumgebung im System.