06 Quiz: Architekturmuster

Das Model in MVC ist verantwortlich für Daten und Geschäftslogik. Es verwaltet die Anwendungsdaten, setzt Geschäftsregeln durch und ist vollständig unabhängig von der Benutzeroberfläche. Die View handhabt die Anzeige (A), der Controller handhabt die Koordination von Benutzereingaben (C), und das Rendern von Templates ist eine View-Verantwortung (D).

Der Controller fungiert als Koordinator in MVC. Er empfängt Benutzereingaben von der View, verarbeitet sie (und aktualisiert möglicherweise das Model) und löst View-Updates aus, wenn sich das Model ändert. Datenspeicherung ist infrastrukturbezogen, visuelles Layout ist Aufgabe der View, und Netzwerkmanagement ist typischerweise getrennt von der MVC-Triade.

Der Hauptvorteil der MVC-Trennung ist die Ermöglichung paralleler Entwicklung. UI-Designer können an Views arbeiten, ohne die Geschäftslogik zu verstehen, während Entwickler an Models arbeiten können, ohne die Oberfläche anzufassen. Diese Trennung ermöglicht auch das Testen von Models unabhängig von der UI und die Verwendung desselben Models mit mehreren Views (Web, Mobile, CLI).

Django verwendet andere Terminologie, aber dasselbe Muster. In Django: Das Model ist weiterhin das Model, das Template entspricht der MVC-View (Präsentation), und Djangos View entspricht dem MVC-Controller (Verarbeitung von Anfragen und Koordination). Dieser Namensunterschied verwirrt oft Entwickler, aber die zugrundeliegende Trennung der Zuständigkeiten ist identisch.

Abhängigkeiten in der Schichtenarchitektur müssen nur abwärts fließen. Die Präsentationsschicht kann von Business abhängen, Business kann von Daten abhängen, aber niemals umgekehrt. Dies stellt sicher, dass niedrigere Schichten unabhängig und wiederverwendbar bleiben.

Eine UI-Komponente (Präsentationsschicht), die direkt die Datenbank (Datenschicht) abfragt, verletzt die Regel “keine Schichten überspringen”. Die Präsentationsschicht sollte durch die Business-Schicht gehen, die dann auf die Datenschicht zugreift.

Richtige Schichtenarchitektur isoliert Technologieänderungen auf bestimmte Schichten. Beim Wechsel der Datenbank muss nur die Datenzugriffsschicht (Repositories, Verbindungscode) geändert werden. Die Business-Schicht ruft weiterhin dieselben Repository-Schnittstellen auf, und die Präsentationsschicht ist völlig unbeeinflusst.

Domänenlogik gehört in die Business/Domänen-Schicht. Dies umfasst Berechnungen, Validierungen und Geschäftsregeln wie die Berechnung der maximalen Steigung aus Messungen. Solche Logik in der Präsentationsschicht zu platzieren, koppelt sie an die UI und macht sie untestbar.

In der Client-Server-Architektur ist der Server die Autorität für Geschäftsregeln, Datenvalidierung und Sicherheitsdurchsetzung. Während Clients Validierung für bessere Benutzererfahrung durchführen können, muss der Server immer validieren, weil Clients umgangen oder manipuliert werden können.

Microservices sind geeignet für große Teams, die unabhängig arbeiten müssen, wenn verschiedene Features unterschiedliche Skalierungsanforderungen haben, oder wenn Technologievielfalt benötigt wird. Die Vorlesung warnt ausdrücklich vor Microservices für kleine Teams, Early-Stage-Produkte und einfache Domänen.

Monolithische Architektur bietet einfacheres Deployment (einmal deployen, nicht mehrere Services koordinieren) und geringere operative Komplexität. Unabhängige Skalierung, Technologievielfalt und Fehlerisolation sind Vorteile von Microservices, nicht von Monolithen.

Ein Technical Spike ist zeitlich begrenzte Recherche (z.B. maximal 2 Tage), um architektonische Fragen vor einer Festlegung zu untersuchen. Dies liefert fundierte Entscheidungen statt Vermutungen. Spikes dienen nicht dem Hetzen oder umfangreicher Dokumentation.

Emergente Architektur bedeutet, genug Entscheidungen zu treffen, um zu starten (Sprache, Framework, Grundstruktur), funktionierende Software zu implementieren und zu refaktorieren, wenn Muster entstehen. Es ist nicht “keine Planung” - du triffst trotzdem initiale Entscheidungen.

Architekturmuster sind wertvoll, weil sie Entdeckungen wiederkehrender Strukturen in erfolgreichen Systemen sind - keine Erfindungen. Sie bieten bewährte Lösungen, gemeinsames Vokabular, bekannte Trade-offs und Community-Support.