© Liashko/Shutterstock.com
Entwickler Magazin
Die Zwiebelarchitektur und ihre Vorzüge

Zwiebeln statt Layer

Zwiebeln schneiden brennt in den Augen, nicht aber in der Softwarearchitektur - ganz im Gegenteil. Die Zwiebelarchitektur (Onion Architecture), eingeführt durch Jeffrey Palermo, stellt die weitbekannte Layer-Architektur (Layered Architecture) auf den Kopf. Lernen Sie die Zwiebelarchitektur und ihre Vorteile in diesem Artikel an einem praktischen Beispiel kennen. Kombiniert mit der Strukturierung Ihres Codes nach Features wird Ihre Architektur nach diesem Muster einfacher zu verstehen, zu ändern und zu erweitern sein.

Daniel Marbach


Für lange Zeit war die Standardantwort auf die Frage, wie Komponenten und Klassen in der Softwarearchitektur organisiert werden sollen: mit Layern. Bevor wir genauer betrachten, welche Vorzüge Layer mit sich bringen und wie sie in der Softwarearchitektur integriert werden, ist es zunächst erforderlich, mit Missverständnissen im Bereich Layer und Tier aufzuräumen.

Layer vs. Tier

Wenn wir über Layer sprechen, meinen wir die logische Trennung oder Aufteilung von Komponenten und ihre Funktionalität, nicht aber den physikalischen Aufenthaltsort einer Komponente auf verschiedenen Servern. Der Begriff Tier hingegen meint die physikalische Verteilung einer Komponente und Funktionalität auf separaten Servern inklusive der Netzwerktopologie. Mit Tier ist das physikalische Verteilungsmuster wie z. B. „2-Tier“, „3-Tier“ und „N-Tier“ gemeint. Allerdings haben Layer und Tiers oftmals gleiche oder ähnliche Namen. Da wir in diesem Artikel Letztere behandeln werden, ist es notwendig, Layer zunächst genauer einzuordnen. Was also ist ein Layer – außer einer logischen Auftrennung – und wann wurden Layer eingeführt?

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal analysierten 1996 verschiedene Softwaresysteme. Sie stellten sich die Frage, welche Patterns Softwaresysteme erfolgreich machen und es ermöglichen, die Systeme weiterzuentwickeln, ohne dass dabei so genannte „Big Ball of Mud“-Systeme entstehen. Ihr geballtes Wissen ist im Buch „Pattern-Oriented Software Architecture Volume 1 – A System of Patterns“ publiziert [1].

Eine wichtige Kernaussage des Buchs ist, dass große Softwaresysteme in kleinere Einheiten zerlegt werden müssen, um strukturelle Integrität zu bewahren. Das so genannte Layer-Pattern soll dabei helfen, Applikationen zu strukturieren, indem sie in Gruppen von Subtasks – die wiederum Subtasks bis hin zu einer bestimmten Stufe an Granularität enthalten – zerlegt werden [2], [3]. Die ursprüngliche Idee kam vom OSI-7-Layer-Modell, definiert von der Internationalen Organisation für Normung. All das bildet die Grundlage des originalen N-Lay­er-Modells [4].

Das N-Layer-Modell

In der Hierarchie höher angesiedelte Layer (Layer N+1) nutzen ausschließlich Dienste der darunterliegenden Layer (Layer N). Es sind keine weiteren direkten oder indirekten Abhängigkeiten zwischen den Layern erlaubt. Dadurch schützt jeder Layer die darunterliegenden Layer vor direktem Zugriff. Auf diese Weise wird das Prinzip von Datenkapselung (Information Hiding) e...

Entwickler Magazin
Die Zwiebelarchitektur und ihre Vorzüge

Zwiebeln statt Layer

Zwiebeln schneiden brennt in den Augen, nicht aber in der Softwarearchitektur - ganz im Gegenteil. Die Zwiebelarchitektur (Onion Architecture), eingeführt durch Jeffrey Palermo, stellt die weitbekannte Layer-Architektur (Layered Architecture) auf den Kopf. Lernen Sie die Zwiebelarchitektur und ihre Vorteile in diesem Artikel an einem praktischen Beispiel kennen. Kombiniert mit der Strukturierung Ihres Codes nach Features wird Ihre Architektur nach diesem Muster einfacher zu verstehen, zu ändern und zu erweitern sein.

Daniel Marbach


Für lange Zeit war die Standardantwort auf die Frage, wie Komponenten und Klassen in der Softwarearchitektur organisiert werden sollen: mit Layern. Bevor wir genauer betrachten, welche Vorzüge Layer mit sich bringen und wie sie in der Softwarearchitektur integriert werden, ist es zunächst erforderlich, mit Missverständnissen im Bereich Layer und Tier aufzuräumen.

Layer vs. Tier

Wenn wir über Layer sprechen, meinen wir die logische Trennung oder Aufteilung von Komponenten und ihre Funktionalität, nicht aber den physikalischen Aufenthaltsort einer Komponente auf verschiedenen Servern. Der Begriff Tier hingegen meint die physikalische Verteilung einer Komponente und Funktionalität auf separaten Servern inklusive der Netzwerktopologie. Mit Tier ist das physikalische Verteilungsmuster wie z. B. „2-Tier“, „3-Tier“ und „N-Tier“ gemeint. Allerdings haben Layer und Tiers oftmals gleiche oder ähnliche Namen. Da wir in diesem Artikel Letztere behandeln werden, ist es notwendig, Layer zunächst genauer einzuordnen. Was also ist ein Layer – außer einer logischen Auftrennung – und wann wurden Layer eingeführt?

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal analysierten 1996 verschiedene Softwaresysteme. Sie stellten sich die Frage, welche Patterns Softwaresysteme erfolgreich machen und es ermöglichen, die Systeme weiterzuentwickeln, ohne dass dabei so genannte „Big Ball of Mud“-Systeme entstehen. Ihr geballtes Wissen ist im Buch „Pattern-Oriented Software Architecture Volume 1 – A System of Patterns“ publiziert [1].

Eine wichtige Kernaussage des Buchs ist, dass große Softwaresysteme in kleinere Einheiten zerlegt werden müssen, um strukturelle Integrität zu bewahren. Das so genannte Layer-Pattern soll dabei helfen, Applikationen zu strukturieren, indem sie in Gruppen von Subtasks – die wiederum Subtasks bis hin zu einer bestimmten Stufe an Granularität enthalten – zerlegt werden [2], [3]. Die ursprüngliche Idee kam vom OSI-7-Layer-Modell, definiert von der Internationalen Organisation für Normung. All das bildet die Grundlage des originalen N-Lay­er-Modells [4].

Das N-Layer-Modell

In der Hierarchie höher angesiedelte Layer (Layer N+1) nutzen ausschließlich Dienste der darunterliegenden Layer (Layer N). Es sind keine weiteren direkten oder indirekten Abhängigkeiten zwischen den Layern erlaubt. Dadurch schützt jeder Layer die darunterliegenden Layer vor direktem Zugriff. Auf diese Weise wird das Prinzip von Datenkapselung (Information Hiding) e...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang