Softwarearchitektur beschreibt die grundlegende Struktur und Organisation eines Software-Systems.

Sie definiert die Hauptkomponenten, ihre Beziehungen zueinander und die Prinzipien, nach denen das System aufgebaut ist.

Architekturmuster

MVC - Model View Controller

MVC trennt die Anwendung in drei Hauptkomponenten:

Die drei Schichten:

• Model - Daten und Datenbank-Logik
• View - Benutzeroberfläche
• Controller - Vermittelt zwischen Model und View

┌──────────┐
│   View   │ ← Zeigt Daten an (HTML, CSS)
└─────┬────┘
     │
┌─────▼────────┐
│  Controller  │ ← Verarbeitet Anfragen
└─────┬────────┘
     │
┌─────▼────┐
│  Model   │ ← Datenbankzugriff
└──────────┘

Vorteile:

• ✅ Klare Trennung der Verantwortlichkeiten
• ✅ Testbarkeit (jede Komponente einzeln testbar)
• ✅ Mehrere Views für ein Model möglich

Layered Architecture (Schichtenarchitektur)

Die Anwendung wird in horizontale Schichten aufgeteilt, wobei jede Schicht nur mit der darunterliegenden kommuniziert.

┌─────────────────────────────────┐
│  Presentation Layer (UI)        │ ← Benutzeroberfläche
├─────────────────────────────────┤
│  Business Logic Layer           │ ← Geschäftslogik
├─────────────────────────────────┤
│  Data Access Layer              │ ← Datenbankzugriff
├─────────────────────────────────┤
│  Database Layer                 │ ← Datenspeicherung
└─────────────────────────────────┘

Die 4 Schichten:

1. Presentation Layer (Präsentationsschicht)

• Zeigt Daten dem Benutzer
• Nimmt Eingaben entgegen
• Technologien: HTML, React, JavaFX

2. Business Logic Layer (Geschäftslogik)

• Enthält die Geschäftsregeln
• Verarbeitet Daten
• Validiert Eingaben
• Beispiel: "Ein Kunde darf maximal 10.000€ Kredit haben"

3. Data Access Layer (Datenzugriffsschicht)

• Kommuniziert mit der Datenbank
• ODBC, REST API, ORM-Frameworks
• Kapselt SQL-Abfragen

4. Database Layer (Datenbankschicht)

• Speichert die Daten
• MySQL, PostgreSQL, MongoDB

Microservices-Architektur

Statt einer großen Anwendung (Monolith) baut man viele kleine, unabhängige Services.

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│   User      │  │   Payment   │  │   Order     │
│   Service   │  │   Service   │  │   Service   │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────────────┼────────────────┘
                        │
                  ┌─────▼─────┐
                  │  API      │
                  │  Gateway  │
                  └───────────┘

Charakteristiken:

• Jeder Service hat seine eigene Datenbank
• Services kommunizieren über REST API oder Message Queues
• Unabhängig deploybar
• Können in verschiedenen Programmiersprachen geschrieben sein

Client-Server-Architektur

Der Server stellt Dienste bereit, die Clients nutzen.

┌─────────┐  ┌─────────┐  ┌─────────┐
│ Client  │  │ Client  │  │ Client  │
│  (PC)   │  │ (Handy) │  │ (Web)   │
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┼────────────┘
                  │
            ┌─────▼─────┐
            │  Server   │
            │           │
            └─────┬─────┘
                  │
            ┌─────▼─────┐
            │ Datenbank │
            └───────────┘

Vorteile:

• ✅ Zentrale Datenhaltung
• ✅ Einfache Wartung (nur Server updaten)
• ✅ Zentrale Sicherheit
• ✅ Ressourcen-Sharing

Nachteile:

• ❌ Single Point of Failure (Server fällt aus → alle betroffen)
• ❌ Netzwerk erforderlich
• ❌ Server kann Engpass werden

Monolithische Architektur

Die gesamte Anwendung ist ein einziges, großes Programm.

┌─────────────────────────────────┐
│                                 │
│      Monolithische App          │
│                                 │
│  ┌────────┐  ┌────────┐        │
│  │   UI   │  │ Logic  │        │
│  └────────┘  └────────┘        │
│                                 │
│  ┌──────────────────┐          │
│  │    Database      │          │
│  └──────────────────┘          │
│                                 │
└─────────────────────────────────┘

Vorteile:

• ✅ Einfach zu entwickeln (für kleine Teams)
• ✅ Einfach zu deployen (eine Datei)
• ✅ Einfach zu testen
• ✅ Keine Netzwerk-Latenz zwischen Komponenten

Nachteile:

• ❌ Schwer skalierbar
• ❌ Ein Fehler kann alles zum Absturz bringen
• ❌ Große Code-Basis schwer wartbar
• ❌ Technologie-Lock-in

Architekturprinzipien

Separation of Concerns (Trennung der Zuständigkeiten)

Jede Komponente sollte eine klare Aufgabe haben.

Loose Coupling (Lose Kopplung)

Komponenten sollten möglichst unabhängig voneinander sein.

Vorteil: Änderungen in einer Komponente beeinflussen andere nicht.

High Cohesion (Hohe Kohäsion)

Verwandte Funktionen sollten zusammen in einer Komponente sein.

Don't Repeat Yourself (DRY)

Vermeide Code-Duplikation - schreibe wiederverwendbare Komponenten.

Architekturentscheidungen

Kleine Anwendung, kleines Team:
→ Monolith oder Layered Architecture

Mittlere Anwendung, klare Trennung UI/Logik/Daten:
→ MVC oder Layered Architecture

Große Anwendung, viele Teams, hohe Skalierung:
→ Microservices

Web-Anwendung:
→ Client-Server mit MVC

Cloud vs. On-Premises

Cloud-Modelle:

• SaaS - Software as a Service (z.B. Microsoft 365)
• PaaS - Platform as a Service (z.B. Azure App Service)
• IaaS - Infrastructure as a Service (z.B. AWS EC2)

Speicher-Architekturen

NAS - Network Attached Storage

Datei-basierter Speicher im Netzwerk - wie ein gemeinsamer Ordner.

Verwendung:

• Datei-Sharing
• Backup-Speicher
• Medienserver

SAN - Storage Area Network

Block-basierter Speicher - wie eine lokale Festplatte über Netzwerk.

Verwendung:

• Datenbank-Server
• Virtualisierung
• Hochperformante Anwendungen

Best Practices

Siehe auch:

• MVC
• Microservices
• Design Patterns
• Softwarequalität
• Wartbarkeit
• UML
• REST API