Praktische Angular-Architektur für das echte Leben

Die meisten Angular-Architekturkurse vermitteln Theorie. Nicht dieser.

Hier lernen Sie, echte Probleme zu erkennen, fundierte Entscheidungen zu treffen und Systeme aufzubauen, die auch dann Bestand haben, wenn das Team wächst, sich das Produkt ändert und die Zeit vergeht.

Zwanzig Module. Praxisorientiert. Keine Polsterung.

---

INDEX – Praktische Angular-Architektur für das wirkliche Leben

---

Modul 0 – Systembasis

Punkt 0 ist kein Inhaltsmodul. Es ist die Sichtweise, die Sie in der gesamten Roadmap verwenden werden.

Bevor Sie über spezifische Probleme in Angular sprechen, müssen Sie eine Frage beantworten:

Wie betrachten Sie eine App, die Sie nicht kennen, und entscheiden, ob sie gut oder schlecht ist?

Dafür gibt es vier Grundfertigkeiten.

---

1. Analysieren Sie eine App, ohne den Code zu berühren

Das erste Lesen einer App erfolgt nicht im Editor. Es liegt in der Struktur. Bevor Sie eine einzelne Datei öffnen, können Sie Informationen extrahieren:

• Wie heißen die Ordner? Sagen die Namen, was sie tun?
• Gibt es einen Ordner shared, der mehr wiegt als alles andere?
• Wie viele Verschachtelungsebenen hat die Struktur?
• Verfügen die Module oder Features über Domänennamen oder technische Namen?
• Wo sind die Dienste? Locker oder innerhalb der Merkmale?

Das verrät bereits viel darüber, ob der Entwickler der App in geschäftlichen oder technischen Aspekten gedacht hat.

---

2. Überprüfen Sie die Architektur auf praktische Weise

Beim Überprüfen wird der Code nicht von oben nach unten gelesen. Es werden Fragen mit folgenden Kriterien gestellt:

• Wo lebt die Geschäftslogik?
• Wer weiß was in jeder Schicht?
• Wie viele Websites müssen Sie ändern, um eine neue Funktion hinzuzufügen?
• Gibt es Abhängigkeiten, die in die falsche Richtung gehen?

Ein leitender Architekt beginnt nicht mit der komplexesten Komponente. Beginnen Sie mit den Punkten mit dem höchsten Risiko: gemeinsame Dienste, globaler Status und die Datenzugriffsschicht.

---

3. Erkennen Sie Probleme vor dem Programmieren

Die meisten architektonischen Schäden entstehen durch frühe Entscheidungen, die irrelevant erscheinen:

• „Ich stelle dies vorerst auf einen gemeinsamen Dienst“
• „Die übergeordnete Komponente verwaltet diesen Status, dann verschieben wir ihn“
• „Wir verwenden NgRx für alles, daher ist es konsistent“

Diese Entscheidungen haben Monate später echte Konsequenzen. Das architektonische Kriterium besteht darin, zu wissen, was jede Entscheidung kauft und welche Schulden sie verursacht.

---

4. Wandeln Sie die Theorie in eine echte Checkliste um

Jedes Konzept, das wir in dieser Roadmap sehen werden – intelligente/dumme Komponenten, Zustandsplatzierung, Gottesdienste usw. – muss in einer Frage enden, die Sie sich beim Überprüfen von echtem Code stellen können:

• Weiß diese Komponente, woher die Daten kommen?
• Gibt es mehr als einen Grund, diesen Dienst zu ändern?
• Existiert dieser Staat an zwei verschiedenen Orten?

Wenn Sie ein Konzept nicht in eine Überprüfungsfrage umwandeln können, haben Sie es noch nicht verinnerlicht.

---

Modul 1 – So analysieren Sie eine Angular-App, ohne den Code zu berühren

Die erste Überprüfung der Architektur erfolgt vor dem Öffnen des Editors. Allein aus der Ordnerstruktur und den Dateinamen lassen sich bereits eindeutige Qualitätsmerkmale erkennen. Dies ist, was ein leitender Architekt in den ersten 10 Minuten mit einer unbekannten App tun würde.

Warum ist das wichtig?

• Wenn es lange dauert, Architekturprobleme zu erkennen, steigen die Kosten für deren Behebung exponentiell.
• Eine vom ersten Tag an schlecht gestaltete Struktur wird zu einer technischen Schuld, die das Team Monate später blockiert.
• Durch die Entwicklung eines schnellen visuellen Urteilsvermögens können Sie bessere Entscheidungen treffen, bevor Sie eine einzige Codezeile schreiben.

Schritt 1 – Lesen Sie die Ordnerstruktur als Karte

Die Ordnerstruktur ist die erste sichtbare architektonische Entscheidung. Es zeigt Ihnen, wie das Team seine mentale Welt organisiert hat: Denken sie in Bezug auf Technologie oder in Bezug auf das Geschäft?

Was ist eine Funktion?

Ein Feature ist eine vollständige Geschäftsfunktionalität. Kein Dateityp. Keine technische Schicht.

Denken Sie an eine E-Commerce-App. Die Funktionen sind:

• Der Produktkatalog
• Der Warenkorb
• Der Checkout-Prozess
• Das Benutzerprofil
• Auftragsverwaltung

Jedes davon ist ein Geschäftszweig, der für sich genommen Sinn macht. Ein Benutzer betritt den Katalog, durchsucht ihn, legt ihn in den Warenkorb und checkt aus. Das sind Features.

Modell 1 – Organisation nach technischen Ebenen (im Maßstab problematisch)

Das macht fast jeder, wenn er anfängt, weil es ordentlich erscheint:

src/app/
  components/
    product-card.component.ts
    product-list.component.ts
    cart-item.component.ts
    checkout-form.component.ts
    user-profile.component.ts
  services/
    product.service.ts
    cart.service.ts
    checkout.service.ts
    user.service.ts
  models/
    product.model.ts
    cart.model.ts
    user.model.ts

Das eigentliche Problem: Sie müssen den Checkout-Ablauf ändern. Um zu verstehen, worum es geht, navigieren Sie zwischen drei verschiedenen Ordnern – Sie suchen die Komponente in components/, den Dienst in services/, das Modell in models/. Wenn es eine bestimmte Checkout-Pipe gibt, wird diese in pipes/ mit Pipes aus anderen Features gemischt.

Um eine einzelne Funktion zu ändern, navigieren Sie durch die gesamte App. Das ist Kopplung durch Struktur. Wenn das Team wächst, greifen zwei Personen, die an unterschiedlichen Funktionen arbeiten, ständig auf dieselben Ordner zu → Konflikte im Git, Schwierigkeiten zu wissen, wem was gehört.

Modell 2 – Organisation nach Merkmalen (welche Maßstäbe)

src/app/
  features/
    catalog/
      components/
        product-card.component.ts
        product-list.component.ts
      services/
        product.service.ts
      models/
        product.model.ts
      catalog.routes.ts
    cart/
      components/
        cart-item.component.ts
        cart-summary.component.ts
      services/
        cart.service.ts
      cart.routes.ts
    checkout/
      components/
        checkout-form.component.ts
        order-confirmation.component.ts
      services/
        checkout.service.ts
      checkout.routes.ts
  shared/
  core/

Warum das funktioniert: Wenn Sie auf „Zur Kasse gehen“ tippen, ist alles an der Kasse zusammen. Ein neuer Entwickler weiß genau, wo er suchen muss. Eine Person kann Eigentümer einer gesamten Funktion sein. Sie können ein gesamtes Feature löschen, indem Sie nur seinen Ordner löschen. Git-Konflikte zwischen verschiedenen Features verschwinden fast vollständig.

Die wichtigste Faustregel: Wenn Sie eine Funktion löschen, können Sie dann den gesamten Ordner löschen, ohne etwas anderes anzufassen? Wenn die Antwort „Ja“ lautet, ist die Funktion gut isoliert. Wenn Sie in der gesamten App nach Teilen suchen müssen, ist dies nicht der Fall.

Schritt 2 – Lesen Sie die Namen

Namen sind Dokumentation. Ein schlechter Name verbirgt Absichten und erhöht die kognitive Belastung für jede Person, die den Code liest.

shared/ – was es enthalten sollte und was nicht

shared/ ist für Dinge, die von mehreren Funktionen verwendet werden und KEINE eigene Geschäftslogik haben.

Richtig in shared/:

shared/
  components/
    button/
    modal/
    spinner/
    avatar/
  pipes/
    date-format.pipe.ts
    truncate.pipe.ts
  directives/
    click-outside.directive.ts
  validators/
    email-validator.ts

Es handelt sich um wiederverwendbare UI-Teile oder reine Dienstprogramme. Sie wissen nichts über das Geschäft. Ein ButtonComponent weiß nicht, ob es sich um eine Checkout- oder Benutzerprofil-Schaltfläche handelt. Er weiß nur, wie man ein Knopf ist.

Falsch in shared/:

shared/
  services/
    cart.service.ts           ← lógica de negocio aquí
    user-auth.service.ts      ← pertenece a auth/core
    product-filter.service.ts ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Wenn Sie Dienste mit Geschäftslogik in shared/ sehen, bedeutet das, dass jemand nicht wusste, wo er sie ablegen sollte, und sie dort abgelegt hat. Mit der Zeit wird shared/ zum Allheilmittel der App.

core/ – was es ist und was nicht

core/ ist für eine Singleton-Infrastruktur gedacht, die die gesamte App einmal benötigt.

Richtig in core/:

core/
  services/
    auth.service.ts
    logger.service.ts
    error-handler.service.ts
  interceptors/
    auth.interceptor.ts
    error.interceptor.ts
  guards/
    auth.guard.ts
  models/
    user-session.model.ts

Falsch in core/:

core/
  components/
    dashboard.component.ts  ← eso es una feature
    home.component.ts       ← igual
  services/
    product.service.ts      ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Dies sind Dinge, die einmal instanziiert werden und sich auf die gesamte App auswirken. Der Authentifizierungs-Interceptor fängt alle HTTP-Anfragen für die gesamte App ab, weshalb er sich in core/ befindet.

Vage Namen – Warnsignale

Ein vager Name ist eine aufgeschobene Entscheidung. Wenn jemand data.service.ts erstellt, hat er noch nicht entschieden, über welche Daten dieser Dienst spricht.

was du siehst	Was es bedeuten kann
shared/ sehr groß	Alles, was sonst nirgendwo hinpasste. Es entsteht eine bunte Mischung.
common/	Das Gleiche wie shared/, aber mit schlechterem Namen. Ohne Kriterien dafür, was reinkommt.
utils/ mit Diensten	Als Nutzen getarnte Geschäftslogik. Ernsthafte rote Fahne.
helpers/	Identisch mit utils/. Der Name sagt nichts über Verantwortung aus.
components/ im Stammverzeichnis	Keine Organisation nach Domäne. Alle Komponenten zusammen.
core/ mit 40 Dateien	Schlecht definierter Kern. Als zweites wurde shared/ verwendet.
app.service.ts	Ein Gottesdienst, der darauf wartet, zu wachsen. Maximales Alarmsignal.
data.service.ts	Daten zu was? Unbestimmte Verantwortung aus dem Namen.
helper.service.ts	Am Ende handelt es sich um einen Dienst mit unabhängigen Methoden.
main.component.ts	Was ist „Haupt“? Allgemeiner Name, der echte Verantwortung verbirgt.

Namensregel: Wenn der Dateiname nicht genau sagt, was er tut, macht die Datei wahrscheinlich zu viel oder ist schlecht lokalisiert.

Konkrete Beispiele für vage Namen und was sie verbergen:

• utils/format.ts mit 800 Zeilen: Mischung aus Datumsformatierung + Formularvalidierung + API-Transformation.
• helper.service.ts: endet als Gottesdienst mit unabhängigen Methoden.
• app.service.ts: ein als gesamte App bezeichneter Dienst, der für die gesamte App zuständig ist.

Schritt 3 – Zählen und messen, ohne Dateien zu öffnen

Bevor Sie den Code lesen, können Sie diese Beobachtungen direkt anhand der Struktur machen:

Komponentengröße als Zeichen

Zeichen	Was bedeutet es?
+300-400 Zeilen in einer Komponente	Du machst fast immer zu viel. Es handelt sich nicht um eine absolute Regel, aber es lohnt sich, sie zu untersuchen.
+10 Ein- und Ausgänge	Zu komplexe API. Der Kandidat muss in mehrere Komponenten unterteilt werden.
Direkte HTTP-Aufrufe in der Komponente	Kombinieren Sie Präsentation mit Datenzugriff. Serviceschicht fehlt.
1–2 Komponenten pro Funktion	Sie machen wahrscheinlich zu viel. Mangel an interner Spaltung.
+20 globale Anbieter	Zu viel Staat und zentralisierte Logik. Nicht alles muss global sein.

Globale Dienstleistungen – die Gefahr von providedIn: 'root'

Ein globaler Dienst bedeutet, dass jede Komponente einer beliebigen Funktion diese einspeisen und nutzen kann. Dadurch entstehen unsichtbare Abhängigkeiten zwischen Features, die unabhängig sein sollten.

// Servicio que DEBERÍA ser local a la feature de catalog:
@Injectable({ providedIn: 'root' })  // ← señal de problema
export class ProductFilterService { ... }

// Ahora cualquier componente de cualquier feature puede usarlo.
// Si catalog cambia su lógica de filtrado, puede romper
// algo en una feature aparentemente no relacionada.

Schritt 4 – app.module.ts oder app.config.ts: Worauf Sie achten müssen

In Apps mit Modulen (Angular < 17 oder älter)

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule,
    RouterModule,
    AuthModule,       // ← bien, infraestructura singleton

    ProductModule,    // ← señal de problema
    CartModule,       // ← señal de problema
    CheckoutModule,   // ← señal de problema
    UserModule,       // ← señal de problema
    DashboardModule,  // ← señal de problema
    // Si hay 15+ módulos de features aquí,
    // el lazy loading no está funcionando.
  ],
  providers: [
    ProductService,   // ← si hay 20+ providers aquí,
    CartService,      // hay demasiada centralización
    UserService,
    AuthService,
  ]
})

Feature-Module sollten verzögert (bei Bedarf) geladen und nicht direkt in das Root-Modul importiert werden. Wenn sie alle vorhanden sind, werden sie alle beim Start geladen, auch wenn der Benutzer sie nie benötigt.

In eigenständigen Apps (Angular 17+)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withLazyLoading()),   // ← correcto
    provideHttpClient(withInterceptors([authInterceptor])),
    provideAnimations(),

    ProductService,   // ← esto NO debería estar aquí
    CartService,      // ← pertenece a la feature de cart
  ]
}

Globale Konfigurationsregel: Die globale Konfiguration sollte nur eine Infrastruktur haben, die sich auf die gesamte App auswirkt: Router mit Lazy Loading, HttpClient mit globalen Interceptoren, Animationen, Infrastruktur-Singleton-Dienste (Authentifizierung, Logger, Fehlerhandler). Wenn Sie Feature-Services in der globalen Konfiguration sehen, registriert jemand die Dinge global aus Bequemlichkeit und nicht aus Notwendigkeit.

Vollständige Checkliste – Erstes Lesen einer Angular-App

Struktur

• Ist die Struktur nach Funktionen (Geschäftsbereich) oder nach technischen Schichten organisiert?
• Kann ich eine gesamte Funktion löschen, indem ich nur ihren Ordner lösche, ohne etwas anderes zu berühren?
• Verfügen die Funktionen über geschäftliche Domänennamen (checkout, catalog) oder technische Namen (list, form, detail)?
• Gibt es Ordner mit vagen Namen: utils, helpers, common, misc, data?

shared/ und core/

• Enthält shared/ nur UI-Komponenten und Dienstprogramme ohne Geschäftslogik?
• Enthält core/ nur Singleton-Infrastruktur (Abfangjäger, Wachen, Authentifizierungsdienst)?
• Gibt es Dienste mit Geschäftslogik in shared/?
• Verfügt core/ über Funktionskomponenten oder Domänendienste?

Dienste und Anbieter

• Sind die Geschäftsdienste innerhalb Ihres Leistungsumfangs enthalten oder global verteilt?
• Gibt es mehr als 20 globale Anbieter?
• Importiert das Root-Modul oder app.config.ts Feature-Module direkt (ohne Lazy)?
• Gibt es Dienste mit providedIn: 'root', die lokal für eine Funktion sein sollten?

Namen

• Sagen die Dateinamen genau, was sie tun?
• Gibt es Dateien, deren Name auf irgendeinen Teil der App zutreffen könnte?
• Gibt es eine Datei mit dem Namen app.service.ts, data.service.ts oder helper.service.ts?
• Wiegt shared/ mehr als jedes einzelne Merkmal?

Übung

Suchen Sie auf GitHub nach einem beliebigen öffentlichen Angular-Projekt – es kann Ihr eigenes oder ein Open-Source-Projekt sein. Ohne irgendwelche Dateien zu öffnen, schauen Sie sich einfach die Ordnerstruktur und Namen an:

1. Welches Organisationsmodell verwenden Sie: Funktionen oder technische Schichten?
2. Welche Namen wecken bei Ihnen Zweifel oder Misstrauen?
3. Wo vermuten Sie die Geschäftslogik?
4. Welcher Ordner hat Ihrer Meinung nach die größte Mischung an Verantwortlichkeiten?
5. Könnten Sie eine Funktion löschen, ohne etwas anderes zu berühren?

Teilen Sie mit, was Sie in der Sitzung beobachtet haben, und wir überprüfen es gemeinsam, wie es ein leitender Architekt tun würde.

---

Eingabeaufforderung: Analysieren Sie Ihr Projekt anhand der 4 Punkte

Kopieren Sie diese Eingabeaufforderung und verwenden Sie sie mit einer beliebigen KI (ChatGPT, Claude, Copilot), indem Sie ihr den Ordnerbaum Ihres Projekts übergeben:

---

Analysieren Sie die Projektarchitektur anhand dieser 4 Punkte der Säule 1 und erstellen Sie einen Bericht.

PUNKT 1 – Ordnerstruktur

Analysieren Sie apps/ und libs/ und antworten Sie:

• Erfolgt die Organisation nach Funktionen (Geschäftsbereich) oder nach technischen Ebenen?
• Können Sie eine gesamte Funktion löschen, indem Sie nur ihren Ordner löschen?
• Haben die Features Domänennamen (checkout, catalog) oder technische Namen (list, form, detail)?
• Gibt es Ordner mit vagen Namen: utils, helpers, common, misc, data?
• Zeigt den tatsächlichen Ordnerbaum an, den Sie gefunden haben.

PUNKT 2 – Datei- und Ordnernamen

Durchsuchen Sie das gesamte Projekt und die Liste:

– Dateien mit vagen Namen: data.service.ts, helper.service.ts, app.service.ts, main.component.ts, utils mit darin enthaltenen Diensten. – Dienste mit Geschäftslogik innerhalb von shared/. – Komponenten oder Domänendienste innerhalb von core/.

• Wiegt shared/ mehr als jedes einzelne Merkmal? Anzahl der Dateien.

PUNKT 3 – Globale Dienste

Durchsuchen Sie das gesamte Projekt:

– Alle Dienste mit providedIn: 'root' – listet auf, um welche Dienste es sich handelt und ob sie lokal für ein Feature sein sollen.

• Zählt, wie viele globale Anbieter es insgesamt gibt.
• Identifiziert global registrierte Geschäftsdienste, wenn sie in Ihrem Feature enthalten sein sollten.
• Suchen Sie in libs/services/ nach Diensten, die eindeutig zu einer bestimmten Domain gehören.

PUNKT 4 – Globale Konfiguration (app.config.ts oder app.module.ts)

Suchen Sie die Root-Konfigurationsdatei jeder App und analysieren Sie:

• Was ist global registriert, was nicht sein sollte?
• Werden die Feature-Module mit Lazy Loading geladen oder direkt importiert?
• Gibt es Business Services in der globalen Konfiguration?
• Wie viele Anbieter sind weltweit insgesamt registriert?

BERICHTSFORMAT

Verwenden Sie für jeden Punkt genau diese Struktur:

✅ Was ist gut

(konkrete Liste mit echten Codebeispielen)

⚠️ Zu überprüfende Schilder

(konkrete Liste mit Dateipfad und warum es ein Zeichen ist)

❌ Klare Probleme

(konkrete Liste mit Dateipfad, Problem und tatsächlicher Auswirkung)

Im Endeffekt beinhaltet es:

Zusammenfassung

Eine Tabelle mit den 4 Punkten, einem Status-Emoji (✅ ⚠️ ❌) und einer Abschlusszeile pro Punkt.

Priorisierte nächste Schritte

Liste von maximal 5 spezifischen Aktionen, sortiert nach Auswirkung, mit dem genauen Pfad der Datei oder des Ordners, die berührt werden sollen.

Seien Sie direkt. Erklären Sie nicht, was ein Merkmal oder eine Theorie ist. Analysieren Sie einfach dieses spezifische Projekt und liefern Sie echte Erkenntnisse.