Situationsaufgabe: Software-Architektur
Software-Architektur-Aufgaben im FIAE AP Teil 2 testen, ob du eine Anwendung auf der richtigen Abstraktionsebene entwerfen kannst: Schichten definieren, Abhängigkeiten steuern, passende Muster für den Anwendungsfall wählen und die Wahl begründen. Du musst keine perfekten Architekturdiagramme zeichnen – aber du musst zeigen, dass du den Unterschied zwischen Schichten-Architektur, MVC, Microservices und Hexagonal Architecture kennst und begründen kannst, wann was passt.
1) Das Szenario
Betrieb: Die EduLearn GmbH entwickelt eine neue Lernplattform. Zwei Produkte sind geplant:
- Produkt A – EduLearn Web: Eine klassische Webanwendung für Schulen. Serverseitig gerendert. Kleines Team (3 Entwickler), klarer Scope, kein CI/CD vorhanden.
- Produkt B – EduLearn API-Plattform: Eine API-Plattform für externe Integrationen (andere Bildungstools). Mehrere Teams, unterschiedliche Release-Zyklen je Domäne, hohe Last erwartet. DevOps-Team vorhanden.
Anforderungen für beide Produkte:
- Klare Trennung von Präsentation, Geschäftslogik und Datenzugriff
- Testbarkeit der Geschäftslogik ohne DB oder UI
- Neue Funktionen sollen ohne Refactoring der Kernanwendung ergänzt werden können
2) Teilaufgaben mit Musterlösungen
3) Architekturmuster im Vergleich
Klick ein Muster für Details:
Schichten-Architektur
Präsentation → Logik → Daten
MVC
Model – View – Controller
Microservices
Unabhängige Services
Hexagonal (Ports & Adapters)
Domäne im Kern
4) SOLID-Prinzipien – Grundlage guter Architektur
| Prinzip | Aussage | Beispiel |
|---|---|---|
| S – Single Responsibility | Eine Klasse hat genau eine Verantwortung | Klasse UserService nur für User-Logik – nicht für E-Mail-Versand |
| O – Open/Closed | Offen für Erweiterung, geschlossen für Änderung | Neue Exportformate über neues Interface, nicht durch Änderung bestehenden Codes |
| L – Liskov Substitution | Unterklassen müssen Oberklassen ersetzen können | PKW extends Fahrzeug: überall wo Fahrzeug erwartet wird, muss PKW funktionieren |
| I – Interface Segregation | Viele spezifische Interfaces statt eines großen | Lesbar + Schreibbar statt ein einziges Repository-Interface mit 20 Methoden |
| D – Dependency Inversion | Abhängigkeiten auf Abstraktionen, nicht Implementierungen | Service hängt von IRepository-Interface ab, nicht von konkreter MySQLRepository-Klasse |
Zusammenfassung
Architektur-Aufgaben testen: (1) Architekturwahl mit Begründung (Anforderungen als Argument), (2) MVC-Schichten korrekt aufgeteilt (Model = Daten/Logik, View = Darstellung, Controller = Vermittler), (3) Schichtenmodell mit Abhängigkeitsrichtung, (4) Microservices-Abwägung (wann sinnvoll, wann Overkill). SOLID-Prinzipien als Grundlage immer kennen.
Verwandte Lektionen: Situationsaufgabe OOP · Situationsaufgabe API · Situationsaufgabe Secure Coding · und mehrWeitere relevante LektionenDesign PatternsMVC-ArchitekturPrüfungssimulation FIAE