Jörgs Blog

Schaut euch mal mein neues Clean Code Nuget Package für Minimal und Controller-based APIs an, zur Clean Code gerechten Trennung von Business Logik (Mediator Pattern) und Datenzugriff (Repository Pattern) kombiniert mit der Power des IOSP Patterns.

In einer drei wöchigen Pause zwischen meinem Leben als Microsoft "Premier Field Engineer" und als selbstständiger IT Berater hatte ich endlich mal Zeit mich um die richtig coolen Dinge zu kümmern. Mein erstes Item auf meiner ewig langen Todo Liste war ein cooles Beispiel zu implementieren mit dem man aufwendige Berechnungen mit dem Aktormodell von Akka.Net skalieren kann. Gesagt getan. Während des Programmierens allerdings hatte ich eine Diskussion mit Ralf Westphal über Slack wo es um die wohl für mich relativ neuen Prinzipien IOSP (Integration/Operation Segregation Principle) und PoMO (Principle of mutual oblivion) ging. Also quasi die Trennung von Integration und Operationen bei Methoden (und Klassen) und das "Prinzip der Gegenseitigen Nichtbeachtung". Also habe ich das Aktormodell Beispiel mal auf Seite gelegt. Dazu gibt es mehr in meinem zweiten Blogeintrag in Kürze. :-)

Nach erstem Durchlesen durch Ralfs Artikel dachte ich, der hat doch zuviel schlechtes Zeug geraucht (sorry Ralf). Alles viel zu umständlich und zu akademisch. Es gibt doch SRP (Single Responsibility Principle) und DIP (Dependency Inversion Principle). Hatte er das etwa ignoriert oder nicht verstanden. Totale Verständnislosigkeit machte sich breit. :) Wie wolle er denn die Abhängigkeiten regeln die es ja ohne Zweifel mindestens indirekt durch Interfaces gibt zwischen zwei Modulen? Wie soll eine Leben ohne DIP aussehen? Und wie solle man denn vernünftig testen können ohne richtiges Dependency Injection?

Fragen über Fragen. Also las ich den Artikel öfters und überlegte mir wie ich meinen Code den ich bisher geschrieben hatte in dieses Schema pressen könnte. Nach mehrmaligem Lesen und Ausprobieren dann erschien es mir doch einleuchtend - Nein sogar ziemlich genial. Ich fand sein Code Beispiel etwas verwirrend aufgrund der Tatsache, dass er anstatt des üblichen Request/Response Musters einen CPS (Continuation Passing Style) Ansatz wählte, der zwar schön ist, aber am Anfang mehr verwirrt als das er hilft. Deswegen habe ich mir mal ein Beispiel überlegt erstmal ohne CPS Ansatz aber trotzdem mit IOSP und PuMO (für die Operation Services). Im letzten Sample habe ich dann IOSP mit CPS erweitert zum Vergleich. Also, schreiben wir mal Code :).

Beispiel:

Denken wir uns den folgenden Business Services (BS) aus dessen Aufbau ich in der Praxis schon oft gesehen hab und den ich auch erstmal als SOLID bezeichnen würde. CustomerEarningsService führt irgendeine nicht weiter wichtige Domänen Logik aus.