Signals machen schlechte Architektur nicht besser

Signals sind gut. Wirklich. Feingranuläre Reaktivität, weniger Zone.js-Overhead, klareres Dependency-Tracking — das sind echte Verbesserungen.

Aber: Signals sind ein Reaktivitätsprimitive. Keine Architektur.

Was Signals nicht lösen

• DTO-Leakage: Wenn API-Strukturen direkt in Signals wandern, sind sie trotzdem im falschen Layer.
• Business-Logik in Komponenten: Ein Signal in einer Komponente ist besser als ein Observable — aber Use-Case-Logik gehört trotzdem nicht in die Präsentationsschicht.
• Fehlende Layertrennung: Wer signal() in Komponenten, Services und Facades ohne Konzept verteilt, hat jetzt reaktiven Spaghetti-Code.
• Unkontrollierter Zustand: Signals ohne klares Ownership-Modell sind globale Variablen mit Extra-Schritten.

Was Signals ermöglichen

Mit einem Store-as-Application-Facade-Pattern und Signal Store:

// Facade kapselt Zustand und Logik
export class OrderFacade {
  private store = inject(OrderStore);

  readonly orders = this.store.orders; // computed signals
  readonly isLoading = this.store.isLoading;

  loadOrders() {
    this.store.load();
  }
  submitOrder(data: OrderData) {
    this.store.submit(data);
  }
}

Die Komponente bekommt reaktive Signals, kennt aber keine Store-Interna. Das ist die sinnvolle Nutzung.

Fazit

Signals verbessern die Implementierung guter Architektur. Sie ersetzen sie nicht. Wer vorher schlechte Struktur hatte, hat jetzt schnell reagierenden schlechten Code.