© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 2: IODA: ein neuer Ansatz für Softwarearchitekturen

Wirklich trennen


Die Trennung von Belangen (Separation of Concerns) zeichnet gute Softwarearchitektur aus. Und obwohl hierin weitgehend Einigkeit besteht, wird dies doch im Code für zwei grundlegende Belange meistens vernachlässigt – die Trennung von Integration und Domänenlogik. Eine Architektur getrennt nach Integration, Operation, Data und API (IODA) soll dieses Problem grundsätzlich beseitigen.

Artikelserie

Teil 1: Flow Design: ein neuer Ansatz für Softwaredesign

Teil 2: IODA: ein neuer Ansatz für Softwarearchitekturen

Teil 3: Flow Design mit Java

Teil 4: Flow Design mit Scala

Warum kann man Code nicht wie ein Buch lesen? Warum ist es so schwer, sich in fremden oder durch zeitlichen Abstand fremd gewordenen eigenen Code einzuarbeiten? Ich habe für mich vor allem zwei Gründe ausgemacht: Erstens ist die strukturelle Architektur im Code zumeist nicht wiederzuerkennen. Selbst wenn ein Architekturdokument als roter Faden zu einem Softwaresystem vorliegt, geht die im Dokument beschriebene Struktur im Code verloren. Und zweitens ist die Domänenlogik zumeist über alle Abstraktionsebenen, sprich alle Klassen, des Softwaresystems verteilt. Man möchte schon von verschmiert sprechen. Als Domänenlogik verstehe ich dabei Ausdrücke und Kontrollstrukturen zur Verarbeitung der Domänendaten. So muss man sich zum Verstehen der Verarbeitungslogik einer konkreten Domäneninteraktion, wie einem Programmstart mit Argument oder einem Mausklick zur Verarbeitung von Formulardaten, oft durch alle Abstraktionsebenen des Systems hangeln, da auf jeder Ebene logischer Code sein könnte, der Modifikationen an den beobachteten Domänendaten vornimmt.

Das Wechseln der Abstraktionsebenen, von höherer zu niedrigerer Abstraktion, mit dem Vorsatz der Rückkehr zur höheren Eben, ist für uns Menschen ein großes Problem. Wir sind dafür kognitiv nicht ausgelegt. Dies lässt sich mit dem Lesen eines langen geschachtelten Satzes vergleichen. Ab einer Schachtelungstiefe von fünf bis sieben können die meisten nicht mehr folgen, auch in der natürlichen Sprache. Das kann man zwar trainieren, aber mehr als sieben Schachtelungstiefen wird kaum einer bewältigen. Dies hängt vor allem mit der Beschränktheit unseres Kurzzeitgedächtnisses zusammen.

Wir behelfen uns mit Abstraktionen wie Klassen und Methoden. Wir geben ihnen Namen. Erst dadurch können wir mit ihnen als Abstraktionen gedanklich arbeiten und sie in Abstraktionsebenen anordnen. Aber immer, wenn wir die Anordnung der Abstraktionen mit lokaler Domänenlogik wie Dom...

Java Magazin
Teil 2: IODA: ein neuer Ansatz für Softwarearchitekturen

Wirklich trennen

Die Trennung von Belangen (Separation of Concerns) zeichnet gute Softwarearchitektur aus. Und obwohl hierin weitgehend Einigkeit besteht, wird dies doch im Code für zwei grundlegende Belange meistens vernachlässigt - die Trennung von Integration und Domänenlogik. Eine Architektur getrennt nach Integration, Operation, Data und API (IODA) soll dieses Problem grundsätzlich beseitigen.

Denis Kuniß


Die Trennung von Belangen (Separation of Concerns) zeichnet gute Softwarearchitektur aus. Und obwohl hierin weitgehend Einigkeit besteht, wird dies doch im Code für zwei grundlegende Belange meistens vernachlässigt – die Trennung von Integration und Domänenlogik. Eine Architektur getrennt nach Integration, Operation, Data und API (IODA) soll dieses Problem grundsätzlich beseitigen.

Artikelserie

Teil 1: Flow Design: ein neuer Ansatz für Softwaredesign

Teil 2: IODA: ein neuer Ansatz für Softwarearchitekturen

Teil 3: Flow Design mit Java

Teil 4: Flow Design mit Scala

Warum kann man Code nicht wie ein Buch lesen? Warum ist es so schwer, sich in fremden oder durch zeitlichen Abstand fremd gewordenen eigenen Code einzuarbeiten? Ich habe für mich vor allem zwei Gründe ausgemacht: Erstens ist die strukturelle Architektur im Code zumeist nicht wiederzuerkennen. Selbst wenn ein Architekturdokument als roter Faden zu einem Softwaresystem vorliegt, geht die im Dokument beschriebene Struktur im Code verloren. Und zweitens ist die Domänenlogik zumeist über alle Abstraktionsebenen, sprich alle Klassen, des Softwaresystems verteilt. Man möchte schon von verschmiert sprechen. Als Domänenlogik verstehe ich dabei Ausdrücke und Kontrollstrukturen zur Verarbeitung der Domänendaten. So muss man sich zum Verstehen der Verarbeitungslogik einer konkreten Domäneninteraktion, wie einem Programmstart mit Argument oder einem Mausklick zur Verarbeitung von Formulardaten, oft durch alle Abstraktionsebenen des Systems hangeln, da auf jeder Ebene logischer Code sein könnte, der Modifikationen an den beobachteten Domänendaten vornimmt.

Das Wechseln der Abstraktionsebenen, von höherer zu niedrigerer Abstraktion, mit dem Vorsatz der Rückkehr zur höheren Eben, ist für uns Menschen ein großes Problem. Wir sind dafür kognitiv nicht ausgelegt. Dies lässt sich mit dem Lesen eines langen geschachtelten Satzes vergleichen. Ab einer Schachtelungstiefe von fünf bis sieben können die meisten nicht mehr folgen, auch in der natürlichen Sprache. Das kann man zwar trainieren, aber mehr als sieben Schachtelungstiefen wird kaum einer bewältigen. Dies hängt vor allem mit der Beschränktheit unseres Kurzzeitgedächtnisses zusammen.

Wir behelfen uns mit Abstraktionen wie Klassen und Methoden. Wir geben ihnen Namen. Erst dadurch können wir mit ihnen als Abstraktionen gedanklich arbeiten und sie in Abstraktionsebenen anordnen. Aber immer, wenn wir die Anordnung der Abstraktionen mit lokaler Domänenlogik wie Dom...

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