Die Layered Architecture ist ein bewährtes architektonisches Muster, das Systeme in verschiedene Schichten unterteilt, wobei jede Schicht eine spezifische Verantwortung hat. Dieses Muster fördert die Modularität und ermöglicht eine klare Trennung von Anliegen, was die Wartbarkeit und Erweiterbarkeit von Software-Systemen verbessert.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Layered Architecture strukturiert eine Software in übereinanderliegende Schichten mit klaren Zuständigkeiten und gerichteten Abhängigkeiten, etwa Präsentation, Anwendung, Domäne und Infrastruktur.
Schichtenmodelle übertragen das Prinzip der Separation of Concerns aus Softwaretechnik und Systemarchitektur in eine konkrete Struktur. Mehrschichtige und n-tier-Architekturen etablierten die Trennung von Benutzeroberfläche, Geschäftslogik und Datenzugriff als verbreitete Organisationsform.
Denke an ein Gebäude mit Stockwerken: Oben liegt die Bedienung, darunter die Anwendungslogik, im Kern die fachlichen Regeln und unten technische Adapter. Ein Stockwerk nutzt definierte Dienste des darunterliegenden, damit Änderungen begrenzt bleiben.
Sie bündelt Code mit einer gemeinsamen Aufgabe und verbirgt interne Details vor anderen Schichten.
Sie legt fest, welche Schicht welche andere kennen und aufrufen darf.
Das Muster unterstützt Teams dabei, Verantwortlichkeiten zu ordnen und Änderungsfolgen einzugrenzen. Es wird problematisch, wenn Schichten nur noch technische Durchreiche sind oder Abhängigkeiten ihre Grenzen durchbrechen.
Wo dieser Baustein im Themenmodell verortet ist.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.