Derzeit führen viele Projektteams µServices und damit auch Eric Evans‘ Domain-Driven Design (DDD) bei sich ein. Oft geht es darum, den Legacy-Monolithen abzulösen. Viel zu lange hat er die Firma gequält. Er erfüllt die Qualitätsanforderungen einfach nicht mehr und schafft dabei viele Probleme. Er soll weg und durch µServices ersetzt werden. Dabei hat sich herumgesprochen, dass DDD als Zauberwaffe zur Zerlegung von Monolithen eingesetzt werden kann. Doch der Weg dahin ist steinig und oft werden auf der Strecke viele kostbare Perlen des DDDs übersehen. Ungewollt und überraschend führt der Weg manches Mal in eine irritierende Richtung, manchmal auch ins Abseits. Richtig angewendet eröffnet DDD allerdings ungeahnte Möglichkeiten. Schade, wenn man die verpasst…
Auf diese Wege, die Stolpersteine und Perlen möchte ich in diesem Artikel zu sprechen kommen. Der Artikel soll die Tiefen von DDD aufzeigen und bei der Beantwortung der folgenden Frage helfen: Ist DDD für mein Projekt das Richtige? Wenn „Ja“, dann lass‘ es uns aber richtig angehen.
Fachartikel Informatik aktuell online, 09. September 2020