Wartbares Design dank CQRS

Trennungsfreuden

Stefan Priebsch


Mit den Daten in unseren Applikationen ist es wie mit Quellcode: Es wird häufiger gelesen als geschrieben. Während bei klassischen Enterprise-Anwendungen oft tausende Lesezugriffe auf einen Schreibzugriff kommen (denken Sie an den Kantinenplan, das Herz und die Seele vieler Corporate Intranets), liegt bei aktuellen Webanwendungen das Verhältnis von Lese- zu Schreibzugriffen typischerweise zwischen 7 zu 1 und 10 zu 1.

Der Begriff „Separation of Concerns“, also die Trennung unterschiedlicher Belange, geht auf den Informatikpionier Edsger Dijkstra zurück. Dieser schrieb 1974 in einem Paper: „But nothing is gained – on the con­trary! – by tackling these various aspects simultaneously. It is what I sometimes have called ‘the separation of conerns’, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of.“ [1].

Über die Jahre hat sich „Separation of Concerns“ zu einer zentralen „goldenen Regel“ beim Programmieren entwickelt. Man kann viele Fehler im Entwurf oder bei der Programmierung damit erklären, dass unterschiedliche Belange nicht sauber voneinander getrennt wurden. „Single Responsibility“, von Robert C. Martin als das „S“ im Akronym SOLID bekannt gemacht, ist übrigens eine Ausprägung von „Separation of Concerns“.

Bertrand Meyer, der Vater der Programmiersprache Eiffel, schrieb in seinem 1988 erschienenen Buch „Object-oriented Software Construction“ [2] ausführlich darüber, dass Methoden entweder Auskunft über den Zustand eines Objekts geben sollen (Getter), oder den Zustand eines Objekts ändern (Setter oder auch Mutatoren genannt). Er schrieb: „Asking a question should not change the answer“ und meinte damit, dass ein Lesezugriff nicht den Zustand eines Objekts ändern darf.

Einer kann lesen, einer kann schreiben

Das mag heute wenig überraschend klingen, denn bewusst oder unbewusst halten sich die meisten Programmierer heute an diese Regel. Es gibt einige Ausnahmen wie etwa Operationen, die unteilbar sein sollen (get and increment) oder die Abfrage der letzten aufgetretenen Fehlermeldung, die typischerweise den „Fehlerspeicher“ löscht und damit den Zustand des Objekts ändert. Wenn aber die Idee der Trennung unterschiedlicher Belange, also der Trennung von Lese- und Schreibzugriffen auf der Ebene einzelner Objekte eine so gute (und zentrale) Idee ist, warum wenden wir sie dann nicht auch auf ganze Applikationen an?

Sehen wir uns einmal ein einfaches Beispiel an: das API eines einfachen ...

Wartbares Design dank CQRS

Trennungsfreuden

Stefan Priebsch


Mit den Daten in unseren Applikationen ist es wie mit Quellcode: Es wird häufiger gelesen als geschrieben. Während bei klassischen Enterprise-Anwendungen oft tausende Lesezugriffe auf einen Schreibzugriff kommen (denken Sie an den Kantinenplan, das Herz und die Seele vieler Corporate Intranets), liegt bei aktuellen Webanwendungen das Verhältnis von Lese- zu Schreibzugriffen typischerweise zwischen 7 zu 1 und 10 zu 1.

Der Begriff „Separation of Concerns“, also die Trennung unterschiedlicher Belange, geht auf den Informatikpionier Edsger Dijkstra zurück. Dieser schrieb 1974 in einem Paper: „But nothing is gained – on the con­trary! – by tackling these various aspects simultaneously. It is what I sometimes have called ‘the separation of conerns’, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of.“ [1].

Über die Jahre hat sich „Separation of Concerns“ zu einer zentralen „goldenen Regel“ beim Programmieren entwickelt. Man kann viele Fehler im Entwurf oder bei der Programmierung damit erklären, dass unterschiedliche Belange nicht sauber voneinander getrennt wurden. „Single Responsibility“, von Robert C. Martin als das „S“ im Akronym SOLID bekannt gemacht, ist übrigens eine Ausprägung von „Separation of Concerns“.

Bertrand Meyer, der Vater der Programmiersprache Eiffel, schrieb in seinem 1988 erschienenen Buch „Object-oriented Software Construction“ [2] ausführlich darüber, dass Methoden entweder Auskunft über den Zustand eines Objekts geben sollen (Getter), oder den Zustand eines Objekts ändern (Setter oder auch Mutatoren genannt). Er schrieb: „Asking a question should not change the answer“ und meinte damit, dass ein Lesezugriff nicht den Zustand eines Objekts ändern darf.

Einer kann lesen, einer kann schreiben

Das mag heute wenig überraschend klingen, denn bewusst oder unbewusst halten sich die meisten Programmierer heute an diese Regel. Es gibt einige Ausnahmen wie etwa Operationen, die unteilbar sein sollen (get and increment) oder die Abfrage der letzten aufgetretenen Fehlermeldung, die typischerweise den „Fehlerspeicher“ löscht und damit den Zustand des Objekts ändert. Wenn aber die Idee der Trennung unterschiedlicher Belange, also der Trennung von Lese- und Schreibzugriffen auf der Ebene einzelner Objekte eine so gute (und zentrale) Idee ist, warum wenden wir sie dann nicht auch auf ganze Applikationen an?

Sehen wir uns einmal ein einfaches Beispiel an: das API eines einfachen ...

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