Softwarearchitektur mit .NET/C#, Angular und TypeScript: Drei Ansätze für skalierbare Anwendungen

Die Technologieauswahl ist bei der Entwicklung moderner Softwareplattformen nur der erste Schritt. ASP.NET Core mit C# im Backend sowie Angular und TypeScript im Frontend bilden eine solide technische Grundlage. Ob eine Lösung jedoch langfristig wartbar, erweiterbar und zuverlässig betrieben werden kann, hängt wesentlich von ihrer Architektur ab.

Insbesondere dann, wenn eine Anwendung verschiedene Fachbereiche, Geräte, Standorte oder Entwicklungsteams verbindet, entstehen zentrale Fragen: Wo liegen die fachlichen Grenzen? Wie werden Komponenten voneinander entkoppelt? Wie viel Verteilung ist sinnvoll? Und welche Teile müssen auch ohne permanente Netzwerkverbindung funktionieren?

Dieser Beitrag vergleicht drei grundsätzlich unterschiedliche Ansätze: einen modularen Monolithen, domänenorientierte Microservices und eine Edge-Cloud-Architektur. Die Beispiele orientieren sich an technischen Plattformen mit Geräteintegration und Betriebsdaten, lassen sich aber ebenso auf Unternehmensanwendungen, Logistik, Energie, Gebäudeautomation oder andere datengetriebene Systeme übertragen. Die Diagramme sind bewusst vereinfachte konzeptionelle Darstellungen, keine vollständigen Deployment- oder Netzwerkpläne.

1. Gemeinsame technische Grundlage: .NET, Angular und TypeScript

Unabhängig vom gewählten Architekturmodell sollten einige technische Prinzipien gleich bleiben. Angular übernimmt die Darstellung und Interaktion im Browser. TypeScript sorgt für klar definierte Datenmodelle, typisierte Schnittstellen im Frontend und wiederverwendbare UI-Komponenten. ASP.NET Core stellt APIs bereit, kapselt Geschäftslogik und integriert Datenquellen sowie externe Systeme.

Für eine konsistente Lösung bieten sich folgende Bausteine an:

• Frontend: Angular mit wiederverwendbaren Komponenten, gemeinsamen Design-Tokens und klar getrennten Features. Wo sinnvoll, können Angular-Standalone-Komponenten und Lazy Loading eingesetzt werden.
• Backend: ASP.NET Core mit C#, Dependency Injection, fachlichen Anwendungsdiensten und konsequenter Trennung von Domänenlogik und Infrastruktur.
• Verträge: versionierte HTTP-APIs, etwa mit OpenAPI; für asynchrone Nachrichten explizite Event-Schemas. DTOs und fachliche Modelle sind nicht automatisch identisch.
• Sicherheit: zentral definierte Identitäten, rollen- oder attributbasierte Berechtigungen, abgesicherte Gerätezugriffe und nachvollziehbare Audit-Ereignisse.
• Betrieb: strukturierte Logs, Metriken, verteilte Traces, automatisierte Tests und eine reproduzierbare Build- und Deployment-Pipeline.
• Geräteintegration: Adapter und Protokollgrenzen statt direkter Zugriffe aus UI oder Domänenlogik auf maschinenspezifische Schnittstellen.

Wichtig ist: Die Frontend-Technologie entscheidet nicht über die Backend-Topologie. Ein Angular-Frontend lässt sich mit jeder der folgenden Varianten kombinieren. Ebenso sind diese Architekturen keine starren Alternativen für alle Zeiten: Ein System kann mit einem modularen Kern beginnen und später gezielt Dienste auslagern.

2. Architekturansatz A: Modularer Monolith

Beim modularen Monolithen läuft die Anwendung typischerweise als eine gemeinsam bereitgestellte Backend-Einheit. Innerhalb dieser Einheit ist sie jedoch in fachlich eigenständige Module aufgeteilt. Ein Modul kann beispielsweise Aufträge, Benutzerverwaltung, Alarmierung, Reporting oder die Anbindung von Geräten abdecken.

Abbildung 1: Ein gemeinsames Deployment mit bewusst definierten Modulgrenzen. Die Darstellung der Geräteintegration ist schematisch; Adapter greifen in einer realen Lösung über die Anwendungsschicht und nicht über die Datenbank auf die Fachlogik zu.

Aufbau und Verantwortlichkeiten

Die Angular-Anwendung kommuniziert über HTTP beziehungsweise bei Echtzeitmeldungen über einen passenden Push-Kanal mit dem ASP.NET-Core-Backend. Dieses stellt API-Endpunkte und Anwendungsfälle bereit. Die einzelnen fachlichen Module besitzen getrennte Services, Datenzugriffsschichten und interne Verträge. Eine gemeinsame physische Datenbank ist möglich, dennoch sollten die Module nicht beliebig auf die Tabellen anderer Module zugreifen. Getrennte Schemas und klare Eigentumsregeln helfen, Grenzen durchzusetzen.

Eine mögliche Projektstruktur wäre:

src/
  Web/                    # Angular / TypeScript
  Platform.Api/           # ASP.NET Core, Auth, API-Endpunkte
  Modules/
    Orders/
    Assets/
    Alarms/
    Identity/
    Reporting/
  BuildingBlocks/         # gezielte technische Querschnittsfunktionen
  Integrations/           # Geräte- und Fremdsystemadapter

Die Gefahr besteht darin, dass ein vermeintlich modularer Monolith zu einer unstrukturierten Ansammlung gegenseitiger Abhängigkeiten wird. Eine saubere Modularchitektur verlangt daher überprüfbare Regeln: Keine zyklischen Referenzen, keine fremden Datenzugriffe ohne definierten Vertrag und automatische Architekturtests in der CI-Pipeline.

Stärken und Grenzen

Der Ansatz hat einen vergleichsweise überschaubaren Betriebsaufwand. Änderungen über mehrere Module hinweg lassen sich einfacher koordinieren, und Transaktionen innerhalb einer Datenbank sind oft unkomplizierter als in verteilten Systemen. Debugging und lokale Entwicklung sind ebenfalls leichter.

Andererseits teilen sich die Module den Release-Zyklus und weitgehend dieselben Laufzeitressourcen. Bei sehr unterschiedlichen Lastprofilen oder autonom arbeitenden Teams kann diese Kopplung problematisch werden. Ein modularer Monolith ist deshalb vor allem dann attraktiv, wenn fachliche Ordnung und schnelle Lieferung wichtiger sind als unabhängige Deployments.

3. Architekturansatz B: Domänenorientierte Microservices

Microservices trennen die Plattform in eigenständig betreibbare Dienste, die entlang fachlicher Verantwortlichkeiten zugeschnitten werden. Entscheidend ist nicht die Anzahl der Services, sondern die Qualität der Bounded Contexts: Jeder Service besitzt einen klaren Zweck, einen nachvollziehbaren Datenverantwortungsbereich und definierte Schnittstellen.

Abbildung 2: Fachlich abgegrenzte Dienste mit API-Gateway und Ereigniskommunikation. Für die Datenhaltung gilt als Architekturprinzip: Jeder Dienst greift direkt nur auf seine eigenen Daten zu; ein Event-Bus ist kein Datenbankzugriffspfad.

Aufbau und Kommunikation

Ein Angular-Frontend verwendet stabile APIs. Ein API-Gateway oder Backend-for-Frontend kann Authentifizierung, Routing, Aggregation und clientgerechte Endpunkte bündeln. Dahinter liegen eigenständige ASP.NET-Core-Services, beispielsweise für Aufträge, Anlagen, Alarme oder Auswertungen.

Nicht jede Kommunikation sollte asynchron erfolgen. Ein Benutzer möchte etwa die Details eines Auftrags unmittelbar abrufen. Dafür eignet sich eine synchrone HTTP-Anfrage. Eine Zustandsänderung wie OrderCompleted oder AlarmRaised kann dagegen als Ereignis veröffentlicht werden. Andere Dienste reagieren darauf, ohne dass der ursprüngliche Dienst ihre konkrete Implementierung kennen muss.

Wichtige technische Entscheidungen sind dabei:

• Datenhoheit: Jeder Service verwaltet sein eigenes Datenmodell. Direkte Datenbankzugriffe zwischen Services sollten vermieden werden.
• Ausfallsicherheit: Timeouts, Retry mit Backoff, Circuit Breaker und Idempotenz müssen bewusst entworfen werden. Wiederholte Nachrichten dürfen nicht zu doppelten Geschäftsvorgängen führen.
• Konsistenz: Fachliche Prozesse über mehrere Services hinweg benötigen häufig Eventual Consistency und gegebenenfalls Saga-ähnliche Abläufe.
• Nachrichtenqualität: Outbox-Mechanismen und nachvollziehbare Korrelation helfen, verlorene oder doppelt verarbeitete Ereignisse zu beherrschen.
• Verteilte Diagnose: Log-, Metrik- und Trace-Korrelation über Servicegrenzen hinweg ist unverzichtbar.

Stärken und Grenzen

Dienste können unabhängig deployt und bei entsprechendem Bedarf separat skaliert werden. Teams erhalten klarere technische Eigentümerschaft und können einzelne Bereiche unabhängig weiterentwickeln. Allerdings entstehen zusätzliche Netzwerkausfälle, komplexere Tests, Versionskonflikte, verteilte Zustände und ein deutlich anspruchsvollerer Betrieb.

Microservices sollten daher keine Standardantwort auf das Wort „skalierbar“ sein. Ihr Mehrwert entsteht besonders dort, wo unterschiedliche Lastprofile, echte fachliche Unabhängigkeit oder mehrere autonom arbeitende Teams diese Komplexität rechtfertigen.

4. Architekturansatz C: Edge-Cloud-Plattform

In technischen und verteilten Systemen kommt eine andere Frage hinzu: Wo muss eine Funktion ausgeführt werden? Eine zentrale Anwendung kann nicht jede Aufgabe übernehmen, wenn Netzwerkverbindungen unterbrochen werden oder lokale Funktionen niedrige Latenzen erfordern.

Eine Edge-Cloud-Architektur trennt deshalb lokale, standortnahe Komponenten von zentralen Plattformdiensten. Auf einem Industrie-PC, Gateway oder lokalen Server können .NET-Dienste Betriebsdaten erfassen, puffern und lokale Funktionen bereitstellen. Zentrale Dienste übernehmen beispielsweise Historisierung, standortübergreifende Auswertungen, Identitätsverwaltung oder die Verteilung freigegebener Konfigurationen.

Abbildung 3: Lokale Funktionsfähigkeit und zentrale Plattformdienste werden durch eine abgesicherte, fehlertolerante Synchronisation verbunden.

Aufbau und Betriebsmodell

Die lokale Ebene stellt unabhängig von der zentralen Verbindung die Funktionen sicher, die am Standort verfügbar bleiben müssen. Dazu gehören ein persistenter Nachrichtenpuffer, Geräteschnittstellen, Zustandsverwaltung und geeignete lokale Benutzeroberflächen. Das Angular-Frontend kann abhängig vom Einsatzfall lokal oder zentral ausgeliefert werden.

Zwischen Edge und Zentrale werden Daten idealerweise über gesicherte Kanäle übertragen. Der Synchronisationsprozess benötigt definierte Regeln für Reihenfolge, Wiederholungen, Konflikte, Verbindungsabbrüche und Wiederanlauf. Ein Store-and-Forward-Verfahren kann dafür sorgen, dass Betriebsereignisse zunächst lokal gespeichert und später zuverlässig übertragen werden.

Für verteilte Standorte sind zusätzliche Architekturbausteine entscheidend:

• Offline-Fähigkeit: Welche Funktionen müssen ohne Verbindung verfügbar sein, und wie lange muss der Puffer reichen?
• Versionierung: Welche Kombinationen von Edge-Software, zentraler API und Geräteschnittstellen sind kompatibel?
• Gerätesicherheit: Gegenseitige Authentifizierung, Zertifikatsverwaltung und die Trennung von Betriebsnetz und übergeordnetem IT-Netz.
• Updates: Signierte Pakete, gestaffelte Rollouts und Rückfallstrategien bei fehlgeschlagenen Aktualisierungen.
• Datenfluss: Welche Messwerte werden kontinuierlich übertragen, welche nur verdichtet oder ereignisbasiert?

Bei echter Maschinensteuerung ist ausserdem eine wichtige Grenze zu beachten: Sicherheitskritische Funktionen und harte Echtzeitregelung gehören in dafür ausgelegte Steuerungs- und Sicherheitssysteme. Eine allgemeine ASP.NET-Core-Anwendung auf einem Standardbetriebssystem ersetzt weder SPS- noch zertifizierte Sicherheitsfunktionen.

Stärken und Grenzen

Der Ansatz reduziert die Abhängigkeit von einer permanenten Verbindung, ermöglicht eine standortnahe Verarbeitung und schafft dennoch eine gemeinsame Daten- und Servicebasis. Sein Preis ist ein komplexerer Lebenszyklus: Updates auf vielen Geräten, Zustandsabgleich, Kompatibilitätsmanagement und deutlich mehr Betriebsvarianten.

Die Edge-Cloud-Architektur ist zudem keine direkte Alternative zur Entscheidung Monolith oder Microservices. Auch die lokale Edge-Software oder die zentrale Plattform kann intern modular-monolithisch oder serviceorientiert aufgebaut sein. Edge-Cloud beschreibt zunächst die Verteilung von Verantwortlichkeiten zwischen Ausführungsorten.

5. Übergreifende Architekturentscheidungen

Die Wahl einer Topologie allein garantiert keine Qualität. Für alle drei Ansätze sind die folgenden Entscheidungen mindestens ebenso wichtig.

Fachliche Grenzen statt technischer Schichten allein

„Controller“, „Service“ und „Repository“ sind nützliche technische Begriffe, beschreiben aber noch keine Facharchitektur. Domänenorientierte Module sollten über fachliche Verantwortlichkeiten definiert werden: Wer besitzt einen Auftrag? Wer entscheidet über einen Alarmstatus? Wer verwaltet die Konfiguration eines Geräts? Erst daraus ergibt sich, welche Komponenten Daten ändern dürfen und welche nur lesend darauf zugreifen.

Verträge, Versionierung und Kompatibilität

APIs und Ereignisse brauchen einen klaren Lebenszyklus. Dazu gehören versionierte Schemas, Abwärtskompatibilität, Deprecation-Regeln und Contract-Tests. Besonders in Anlagen oder verteilten Installationen lassen sich nicht alle Komponenten gleichzeitig aktualisieren. Zeitweilige Versionsunterschiede müssen daher als Normalfall geplant werden.

Frontend-Architektur und Design System

Für Angular bietet sich die Trennung zwischen einer gemeinsamen Anwendungshülle, fachlichen Features und UI-Bibliotheken an. Gemeinsame Komponenten können Navigation, Tabellen, Formulare, Meldungen, Zugriffssteuerung und Visualisierungen abdecken. Ein Design System vereinheitlicht Erscheinungsbild und Bedienlogik. Es sollte jedoch nicht dazu führen, dass jedes Fachmodul von einem zentralen Team abhängig wird, sobald eine kleine Änderung benötigt wird.

Microfrontends sind eine mögliche Ergänzung bei unabhängigen Frontend-Releases. Sie bringen aber eigene Integrations- und Versionsprobleme mit sich und sollten deshalb nicht reflexartig eingeführt werden.

Qualitätssicherung und Architektur-Governance

Automatisierte Tests sollten passend zur jeweiligen Grenze organisiert werden: Unit-Tests für Fachlogik, Integrationstests für Datenbanken und Adapter, Contract-Tests für Schnittstellen und gezielte End-to-End-Tests für kritische Benutzerabläufe. Ergänzend helfen Architekturentscheidungsprotokolle (ADRs), statische Qualitätsprüfungen und regelmässige Reviews, technische Leitlinien nachvollziehbar zu halten.

Eine belastbare Entwicklerplattform besteht daher nicht nur aus Quellcode, sondern auch aus Standards, Beispielen, Dokumentation, Templates, Build-Pipelines und klaren Verantwortlichkeiten. Erst diese Kombination macht eine Architektur für mehrere Teams langfristig nutzbar.

6. Gegenüberstellung: Vor- und Nachteile

Die folgende Tabelle bewertet keine absolute Qualität. Sie zeigt typische Trade-offs unter der Annahme, dass alle Varianten fachlich sauber entworfen und professionell betrieben werden.

Abbildung 4: Die Varianten setzen unterschiedliche Schwerpunkte. Die Edge-Cloud-Aufteilung kann mit einem modularen Monolithen oder mit Microservices kombiniert werden.

Welche Variante passt unter welchen Bedingungen?

Ein modularer Monolith ist häufig der pragmatischste Ausgangspunkt. Er vermeidet unnötige Verteilung und erlaubt es, fachliche Grenzen früh festzulegen. Wenn die Module konsequent voneinander getrennt werden, können ausgewählte Teile später eigenständig betrieben werden.

Microservices sind dann sinnvoll, wenn der organisatorische und technische Nutzen einer getrennten Bereitstellung tatsächlich entsteht. Mehrere Entwicklungsteams allein reichen als Begründung nicht aus. Ausschlaggebend sind eigenständige fachliche Verantwortlichkeiten, voneinander unabhängige Änderungszyklen und reale Anforderungen an Skalierung oder Ausfallsicherheit.

Edge-Cloud wird relevant, sobald lokale Verfügbarkeit, Geräteintegration und zentrale Dienste gleichzeitig benötigt werden. Diese Entscheidung betrifft zunächst die Verteilung zwischen Standorten und Zentrale. Innerhalb beider Bereiche kann weiterhin ein modularer Monolith oder eine Microservices-Struktur sinnvoll sein.

7. Ein evolutionärer Weg zur tragfähigen Plattform

In vielen Projekten bietet sich deshalb kein einmaliger Architekturentscheid für die gesamte Zukunft an, sondern ein evolutionäres Vorgehen mit überprüfbaren Übergängen:

1. Domänen und Qualitätsziele bestimmen: Fachgrenzen, Latenz, Verfügbarkeit, Offline-Anforderungen, Änderungsrate, Teamzuständigkeiten und Sicherheitsbedarf konkret dokumentieren.
2. Einen modularen Kern aufbauen: Wiederverwendbare UI-Bausteine, klar gekapselte .NET-Module, definierte APIs und automatisierte Qualitätsprüfungen etablieren.
3. Messbare Engpässe identifizieren: Nicht vermutete, sondern tatsächliche Probleme mit Releases, Skalierung, Kopplung oder Betrieb erfassen.
4. Gezielt Dienste ausgliedern: Nur Komponenten trennen, deren unabhängiger Betrieb einen nachweisbaren Nutzen bringt. Datenhoheit und Verträge müssen vor der Auslagerung geklärt sein.
5. Lokale Ausführung dort ergänzen, wo nötig: Geräteschnittstellen und offlinekritische Prozesse auf Edge-Systeme verlagern, mit expliziter Synchronisations- und Update-Strategie.
6. Architektur laufend überprüfen: ADRs, Betriebsmesswerte, Tests und Feedback aus den Entwicklungsteams als Grundlage für weitere Änderungen nutzen.

Dabei sollte nicht die Anzahl der Services oder die Modernität eines Technologiebegriffs im Vordergrund stehen. Das eigentliche Ziel lautet: Die Plattform muss Änderungen aufnehmen können, ohne dass jede neue Anforderung immer grössere Risiken und Kosten verursacht.

Fazit

Mit .NET/C#, Angular und TypeScript lässt sich eine Vielzahl leistungsfähiger Plattformarchitekturen umsetzen. Die entscheidende Frage ist nicht, welche Variante auf einem Diagramm am beeindruckendsten aussieht, sondern welche Struktur die fachlichen Anforderungen, organisatorischen Rahmenbedingungen und den langfristigen Betrieb am besten unterstützt.

Der modulare Monolith priorisiert Verständlichkeit und beherrschbare Komplexität. Microservices ermöglichen unter geeigneten Voraussetzungen unabhängige Entwicklung und Skalierung. Edge-Cloud ergänzt eine notwendige räumliche Trennung, wenn lokale Funktionen auch ohne zentrale Verbindung weiterarbeiten müssen.

Die beste Architektur ist nicht zwangsläufig die verteilteste. Es ist diejenige, deren Grenzen bewusst gewählt sind und deren Komplexität durch konkrete Anforderungen gerechtfertigt wird.

Weiterführende technische Dokumentation

• Microsoft: ASP.NET Core
• Microsoft: Architektur moderner Webanwendungen mit ASP.NET Core und Azure
• Microsoft: .NET Microservices Architecture
• Angular: Offizielle Dokumentation
• OpenTelemetry: Dokumentation