DTO-Leakage ins UI

DTO-Leakage passiert, wenn Datenstrukturen aus der API-Schicht direkt bis in die Komponenten durchgereicht werden — ohne Transformation, ohne Übersetzung.

Wie es aussieht

// API gibt zurück:
interface TaskDto {
  task_id: string;
  created_at: string; // ISO-String
  assigned_to_user_id: string | null;
}

// Und landet direkt in der Komponente:
@Component(...)
export class TaskCardComponent {
  @Input() task: TaskDto; // ← DTO im UI-Layer
}

Das klingt pragmatisch. Es ist eine Zeitbombe.

Was passiert

• Die API ändert ihren Feldnamen? Alle Komponenten brechen.
• Backend-Team wechselt zu snake_case / camelCase? Suchen-Ersetzen durch alle Templates.
• Der created_at-String soll als Date angezeigt werden? Formatierungslogik landet in der Komponente.
• assigned_to_user_id: null muss als „Unzugewiesen” dargestellt werden? Business-Logik im Template.

Die Alternative: ViewModel

interface TaskViewModel {
  id: string;
  createdAt: Date;
  assignee: string; // 'Unzugewiesen' oder Name
}

// Mapping in der Domain-/Adapter-Schicht:
function toViewModel(dto: TaskDto): TaskViewModel {
  return {
    id: dto.task_id,
    createdAt: new Date(dto.created_at),
    assignee: dto.assigned_to_user_id ?? 'Unzugewiesen',
  };
}

Die Komponente kennt nur TaskViewModel. Was dahinter liegt, ist ihr egal.

Der Vorteil

Wenn die API sich ändert, ändert sich der Mapper. Nicht die Komponente. Nicht das Template. Nicht der Test.