Interview mit Sven-Torben Janus

Domain-driven Design: „Wir müssen heute die fachliche Problemstellung so gut wie möglich verstehen“

Hartmut Schlosser

Sven-Torben Janus

Domain-driven Design liegt im Trend. Doch warum überhaupt? Wir haben uns mit Sven-Torben Janus, Software-Architekt bei Conciso und Sprecher auf dem DDD Summit, darüber unterhalten, was DDD ausmacht und wie man sich dem Thema am besten nähern kann.

Domain-driven Design im Trend

DDD Summit: Domain-driven Design liegt im Trend – und das über 15 Jahre nach dem Erscheinen des gleichnamigen Buches von Eric Evans. Warum erlebt DDD gerade jetzt einen Aufschwung?

Wir müssen heute die fachliche Problemstellung so gut wie möglich verstehen.

Sven-Torben Janus: Unternehmen sind heutzutage immer schneller werdenden Änderungen im Markt unterworfen. Das zwingt sie, entsprechend schnell zu agieren und zu reagieren – sie müssen im besten Sinne agil handeln. In meinen Augen erfordert agiles Handeln Selbststeuerungsfähigkeit der handelnden Mitarbeiter und Teams und bringt mich zu der Frage: In welchen Bereichen sollten Teams selbstgesteuert arbeiten und in welchen müssen sie kollaborieren oder sollten sie eben nicht kollaborieren.

Dafür muss man diese Bereiche voneinandner abgrenzen und Kollaborationsmuster etablieren. Stichworte sind hier Abhängigkeiten und Anpassbarkeit. Man kann das aus der rein organisatorischen Brille betrachten, aber Conways Law sollte uns daran erinnern, dass wir diese Strukturen auch in unserer Software wiederfinden.

Meine Erfahrung zeigt, dass dies wirklich problematisch sein kann. Dass beispielsweise ein technischer Schnitt im Sinne der Anpassbarkeit oftmals nicht zielführend ist, ist vielfach diskutiert worden. Es bedarf also besserer Lösungsansätze. Wir müssen heute die fachliche Problemstellung so gut wie möglich verstehen! Nur so ist es möglich, soziotechnische Systeme zu gestalten, die es erlauben, Änderungen fachlicher Natur oder des Marktes anzunehmen und inhärent zu unterstützen. Viele Methoden im Domain Driven Design zielen genau in diese Richtung. Sie machen Domain-driven Design so wertvoll, und das erklärt aus meiner Sicht den aktuellen Trend.

DDD Summit: DDD gilt als Methode zum Bauen von Microservices. Aber damit ist DDD nicht ausreichend definiert, oder? In welchem Verhältnis stehen DDD und Microservices?

Sven-Torben Janus: Microservice-Architekturen teilen Systeme in mehrere Deployments auf. Damit meine ich kleine Teile des Systems, die unabhängig voneinander deployed werden können, unterschiedlichen Entwicklungszyklen unterliegen und über definierte Schnittstellen miteinander kommunizieren. Durch die Aufteilung können unterschiedliche Programmiersprachen bis hin zu unterschiedlichen Technologiestacks für einzelne Teile genutzt werden. Das geht in aller Regel in monolithischen Architekturen nicht, da diese Systeme meist ein gemeinsames Deployment aller Teile erfordern. Das verringert oder verhindert sogar die Selbststeuerung von Teams und schafft Abhängigkeiten, die wahrscheinlich gar nicht gewünscht sind.

Es stellt sich daher die Frage, wie Microservices zu schneiden sind, um die Selbststeuerungsfähigkeit zu erhalten oder zumindest zu fördern. Hier kommen dann Themen wie Bounded Context, Context Maps bzw. insgesamt die strategischen Patterns des Domain-driven Designs zum Tragen. Sie bieten uns eine Orientierung oder zumindest Heuristiken, wie wir die Grenzen zwischen Systemteilen (und damit am besten auch zwischen Teams) unter Berücksichtigung fachlicher Aspekte ziehen.

Warum Domain-driven Design?

DDD Summit: Was ist für dich der Hauptgrund, sich mit DDD zu beschäftigen?

DDD hilft mir, die fachlichen Problemstellungen und Anforderungen in den Vordergrund zu stellen.

Sven-Torben Janus: Ich habe mich während meiner Laufbahn als IT-Berater sehr viel mit dem Thema Software-Architekturen beschäftigt. Als Software-Architekt kann es schnell passieren, dass man sich in vielen technischen und methodischen Details verliert und damit einhergehend die „Accidental Complexity“, wie man so schön sagt, überhand gewinnt. Dabei sollten Architekturen anforderungsgerecht, praktikabel und realisierbar sein. Mit meinen Kunden spreche ich deswegen gerne von „Viable Architecture“.

DDD hilft mir hier, den richtigen Gegenpol zu setzen und die fachlichen Problemstellungen und Anforderungen, die meist genügend inhärente Komplexität mitbringen, in den Vordergrund zu stellen. Architektur hat schließlich keinen Selbstzweck.

DDD Summit: Bei DDD arbeiten Domänenexperten und Software-Entwickler eng zusammen. Ist DDD eher ein methodisches Konzept oder ein technologischer Lösungsansatz?

Sven-Torben Janus: Domain-driven Design stellt die Fachdomäne in den Vordergrund. Technologie ist zweitrangig. Ein methodisches Konzept kann ich nicht sehen, zumindest kein ganzheitliches. Die DDD Community hat in den letzten Jahren viele Methoden hervorgebracht. Viele davon sind sehr nützlich, und ich sehe sie eher als eine Art Methodenkoffer, aus dem man sich bedienen kann.

Einen technologischen Lösungsansatz sehe ich ebenfalls nicht. Domain-driven Design ist für mich ein Mindset, das dabei unterstützt, die wichtigsten geschäftlichen, organisatorischen und technischen Herausforderungen von Unternehmen, die Software entwickeln, anzugehen.

Loslegen mit Domain-driven Design

DDD Summit: Wie kann man sich dem Thema DDD am besten nähern? Welche ersten Schritte empfiehlst du?

Die Community ist heute thematisch viel breiter aufgestellt, als Eric Evans es in seinem Buch ausführen konnte.

Sven-Torben Janus: Ich würde empfehlen, Eric Evans Buch aufmerksam zu lesen. Das ist schließlich die Wurzel der Community, ich denke es ist immer wichtig, auch die Wurzeln zu verstehen. Ansonsten ist die Community heute thematisch viel breiter aufgestellt, als Eric Evans es vor über 15 Jahren in seinem Buch ausführen konnte. Um hier einen Überblick zu bekommen und sich mit anderen auszutauschen, empfehle ich, regelmäßig auf Meetups zu gehen.

Beispielsweise habe ich selbst 2018 das DDD Meetup Rhein/Main gegründet. Dort stellen wir Themen vor, diskutieren kritisch. Außerdem findet man dort viele Gleichgesinnte, teilweise mit langjähriger Erfahrung in diesem Umfeld. Hier bekommt man die richtigen Tipps, sei es zur Einführung taktischer Patterns, zum kollaborativem Modellieren oder zum „Überzeugungsarbeit leisten“ beim Management.

Ansonsten halte ich es eher pragmatisch: Methoden im Team einmal ausprobieren und dabei keine Angst haben auch einmal Fehler zu machen. Wichtig ist, offen zu sein! Wenn man aus einer eher technisch geprägten Ecke kommt, sich den fachlichen Problemstellungen annehmen zu wollen. Kommt man eher aus der fachlichen Ecke, sollte man die Fragestellungen der Entwickler zu würdigen wissen.

DDD Summit: Was möchtest du den Teilnehmern deiner Session vermitteln? Was ist die Kernbotschaft?

Sven-Torben Janus: Mein Kollege Andrej Thiele hat sicherlich den Löwenanteil an der inhaltlichen Ausgestaltung. Er ist ein absoluter Profi im Bereich des agilen Testens. Hier gilt das Credo, Tester früh in den Entwicklungsprozess einzubinden. Wir wollen in unserer Session aufzeigen, wie das im Zusammenhang mit Event Storming sehr früh geschehen kann. Ziel wird es sein, zu erlernen, wie aus Event-Storming-Modellen Testspezifikationen mittels Behaviour-Driven Development (BDD) abgeleitet werden können. Nicht nur theoretisch, sondern anfassbar. Daher werden wir in der Session „Events stormen“ und Tests schreiben. Wir freuen uns schon darauf!

DDD Summit: Wir auch! Vielen Dank, für deine spannenden Einsichten!

Sven-Torben Janus arbeitet als praktizierender Senior Software Architect bei der Conciso GmbH, wo er den Bereich Softwarearchitektur mit verantwortet. Er befürwortet einen agilen und praktikablen Entwurf von Softwarearchitekturen. Sein Unbehagen über technologiegetriebene Designs führte ihn zum Domain-Driven Design und zur Gründung des DDD Meetups Rhein/Main in Frankfurt. Er twittert unter @sventorben und teilt sein Wissen auf Konferenzen, in Artikeln und im Blog auf https://conciso.de/blog/.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: