Patterns für "DDD mit Spring JPA"

Wenn man ein Domain-Driven Design mit Spring JPA umsetzt, helfen bestimmmte Patterns, die immer wieder verwendet werden können.

Video(s) hierzu

• Zykelvermeidung mittels Dependency Inversion Principle
• Adapter-Pattern, um einen Anti-Corruption-Layer zu bauen

Wenn Sie nicht so genau wissen, was mit “Patterns” gemeint ist, dann schauen Sie sich das oben genannte Video dazu an. Die nachfolgende Liste kann Ihnen helfen, häufig wiederkehrende Probleme zu lösen.

Zykelvermeidung mittels Dependency Inversion Principle

Wenn Sie Zykel zwischen Packages in Ihrem Code haben, dann ist eine immer funktionierende Methode die Anwendung des Dependency Inversion Principle. Sie können sich zu diesem Prinzip das oben genannten Video anschauen.

Es gibt auch ein Repo, das das Beispiel aus dem Video aufgreift. Wir haben dieses Repo gemeinsam in einem der ST2-Workshops bearbeitet. In dem after_refactoring-Teilprojekt dieses Repos sehen Sie, wie Sie die Interfaces und Implementierungen wählen müssen, um die Abhängigkeiten aufzulösen.

Dieses Beispiel ist auf der Übungsseite zum Clean-Code- und SOLID-Refactoring noch einmal ausführlich in Teilschritten erklärt. Schauen Sie sich das am besten zusammen mit den Code an. Das können Sie dann als Vorlage für die eigene “Zykelvermeidung” nutzen.

Adapter-Pattern, um einen Anti-Corruption-Layer zu bauen

In den Praktikumsaufgaben gebe ich Ihnen Interfaces vor, die Sie nicht ändern dürfen. Das ist durchaus absolut praxisnah! Nehmen Sie an, Sie bauen ein echtes ECommerce-Portal. Da werden Sie haufenweise APIs bekommen, die Sie nicht ändern können - z.B. von Paypal, von DHL, … Vielleicht gefällt Ihnen der Zuschnitt der APIs nicht (zu groß, zu klein, …), vielleicht verwenden die andere Datenstrukturen als Ihr eigener Code, etc. Jammern hilft nicht, Sie müssen diese (API-)Interfaces so nehmen, wie sie kommen.

Das heißt aber ausdrücklich nicht, dass Sie die Datenstrukturen aus diesen fremden Interface auch in den eigenen Code “durchschleifen” müssen! Bauen Sie einfach einen sogenannten Anti-Corruption-Layer mit Hilfe des Adapter-Patterns.

Das gelbe Interface kommt von außen, mit einer Struktur, die Ihnen nicht gefällt. Die grünen Klassen sind von Ihnen selbst. Sie implementieren das gelbe Interface mit einem AdapterService. Der übersetzt dann die gelbe, fremde Struktur in Ihre eigenen, “grünen” Strukturen, indem er Ihre eigenen Services aufruft. Damit haben Sie die unerwünschten fremden Strukturen aus Ihrem eigenen Code “weggeblockt”. So einfach ist das :-).