„Ich wollte nicht nur das Was, sondern auch das Wie zeigen“

Vaughn Vernon über DDD, Microservices und reaktive Programmierung
Keine Kommentare

Die Geburtsstunde des Domain-driven Design liegt im Jahr 2003. Eric Evans Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ war ein Meilenstein und wird heute noch vielfach rezipiert. Entscheidend zur Verbreitung von DDD hat zudem Vaughn Vernons Werk „Implementing Domain-Driven Design“ beigetragen. Wir haben uns mit Vaughn über die Motivation und Kernideen hinter DDD sowie ihr Verhältnis zu Microservices und reaktiven Architekturen unterhalten.

Entwickler: Das Konzept des Domain-driven Design wurde Anfang der 2000er geprägt. Wenn du dich ein wenig in diese frühe Periode zurückversetzt: Welche Probleme hatte die Softwareentwicklung damals, die dann von der DDD-Bewegung angegangen wurden?

Vaughn Vernon: Ich habe es so wahrgenommen: Zu jener Zeit war die Softwareentwicklung in eine Art Abwärtsspirale geraten. Grund dafür war die Verbreitung einiger meiner Meinung nach äußerst schlechter Spezifikations- und Designentscheidungen durch gewisse Branchenführer. So hatte die damals gerade veröffentlichte J2EE-Spezifikation (jetzt Java EE bzw. Jakarta EE) verheerende Auswirkungen auf das Java-Ökosystem. Die J2EE-Spezifikation förderte die Verwendung von Komponententypen wie EJB Entity Beans, auf deren Konto viele gescheiterte Projekte gingen. Ich glaube nicht, dass die Spezifikationsteams damals ahnten, welche Probleme sie durch ihre Arbeit verursachen würden. Vielleicht wurden ihre Absichten einfach nicht richtig kommuniziert und durch klare Leitmuster unterstützt. Es dauerte jedenfalls Jahre, bis eine angemessene Dokumentation die Runde machte.

Diese Ära war auch für die Industrie eine Herausforderung, da sich der Dotcomboom schnell ausbreitete und viele Start-ups und Teams nicht wussten, welche Technologien sie verwenden sollten. Das Internet war populär geworden und darum herum bildete sich die Dotcomblase.

Auch die Anbieter von Tools wurden von diesem Boom erfasst und versuchten, den finanziellen Aufwärtstrend der Branche mitzugehen. Unter diesen Umständen hatte die große Anzahl von Marktimpulsen, die rein von Profitgier getrieben waren, eine destabilisierende Wirkung. Es wurde schwierig, einen spannenden Job zu finden, wenn im Lebenslauf nicht Buzzwords wie J2EE oder EJB zu finden waren. Und doch war es der breite (Fehl-)Einsatz von Dingen wie J2EE und EJB, der so viel Misserfolg verursachte.

Dazu kam die riesige Informationsflut an schlechten Programmierbeispielen aus Quellen, die vor allem am Geschäftemachen interessiert waren. Viel zu viele junge Programmierer, die neu in die Branche eintraten, aber auch erfahrene Entwickler, die mit den neuen Technologien nicht vertraut waren, wurden von diesen schlechten Beispielen beeinflusst. Ergebnis waren zahlreiche problematische Softwaredesigns, auf kleiner wie auf großer Ebene. Es ist wirklich kein Wunder, dass die Industrie zu der Zeit so viele gescheiterte Projekte und so viele fehlgeleitete Softwareentwickler hervorbrachte.

E: Wie bist du persönlich mit DDD in Kontakt gekommen? Welche Inspirationen hat die DDD-Bewegung dir in dieser Zeit gegeben?

Vernon: Ich hatte bereits viele Techniken im Einsatz, die dann später Domain-driven Design genannt wurden. Die Teams, mit denen ich arbeitete, schwitzten bei der Namensgebung und der Entwicklung von Fluent-Modellen. Meine Auseinandersetzung mit Domänenmodellen begann in den 1980er Jahren, als ich C++ und Smalltalk lernte. Ich programmierte bereits in C, und die Idee von Objekten in C++ schien sehr faszinierend zu sein. Als ich mich jedoch in C++ vertiefte, gab es Probleme sowohl mit den Tools und der Entwicklungsumgebung als auch mit der Sprache und ihrer Verwendung. Ich könnte stundenlang darüber reden, aber ich will nur sagen, dass ich später gelernt habe, wie weit entfernt C++ von einer echten Objektorientierung war.

Erst als ich von Smalltalk und einer seltsamen kleinen Sprache namens C-Talk sowie einer anderen Sprache namens Objective-C erfuhr, begann ich, Objekte richtig zu verstehen. Smalltalk war eine so unglaublich produktive Entwicklungsumgebung, dass ich manchmal nicht glauben konnte, wie schnell ich sehr komplexe Probleme lösen konnte. Es gab einige Bemühungen, C++-Bibliotheken zu erstellen, die Smalltalk nachahmten. Beispielsweise entwickelten die US National Institutes of Health eine solche Bibliothek, die Smalltalk-ähnliche Collections bereitstellte. Aber es gab dabei immer wieder seltsame Kompromisse.

So änderten Smalltalk und der Einfluss, den es auf meine zukünftige Verwendung von C und C++ hatte, alles. Smalltalk war eine natürliche, ausdrucksstarke Umgebung. Fast alles, was wir taten, war effektiv das, was wir heute interne DSLs nennen würden.

Jetzt erinnere dich an meine erste Antwort und stell dir meine Gemütslage vor. Du liebst es, Software zu entwickeln, und du liebst es noch mehr, Software in Smalltalk zu entwickeln. Und dann dieser große Wirrwarr rund um J2EE, EJB und andere unglaublich seltsame Technologien. Früher habe ich stundenlang versucht, den Leuten zu erklären, warum sie J2EE trotz des großen Hypes nicht verwenden sollten. (Ja, einige Teile wie EJB Session Beans sind sinnvoll, solange man es zusammen mit TopLink bzw. später Hibernate verwendet). Ich habe versucht, den Leuten MVC zu erklären – echtes MVC –, und wie diese Konzepte mit der Webentwicklung zusammenhängen. Aber es ist einfach nicht tief genug in die Köpfe eingedrungen.

Während dieser Zeit, also über 15 Jahre nach meiner ersten Verwendung von C++ und Smalltalk, erfuhr ich von DDD. Jemand erwähnte Erics Buch als eine Quelle hilfreicher objekt-orientierter Muster. Ich schätzte die Meinung dieses erfahrenen OO-Programmierers, also musste das Buch gut sein. Am selben Abend fuhr ich zu einem Tech-Buchladen, der „alles“ hatte (ja, die gab es früher), und kaufte Erics Buch. Als ich anfing, zu lesen, spürte ich sofort eine große Resonanz. Es gab natürlich einige Dinge, die mir unklar erschienen, aber vieles davon war so ermutigend. Schließlich fand ich andere mit einem ähnlichen Hintergrund. Und obwohl ich den Begriff Ubiquitous Language nie verwendet hatte, fand ich ihn angesichts meiner Erfahrungen bei der Entwicklung von Businesssprachen in kleinen Teams, die sowohl aus Technikern als auch aus Nichttechnikern bestanden, sehr passend.

Ok, es gab also diese beruhigende Affinität mit meinen bisherigen Aktivitäten. Doch hatte Eric darüber hinaus einige unglaublich kluge und frische Ideen, von denen ich noch nie gehört hatte. Dazu gehörten der Bounded Context und das Context Mapping. Viele der Softwareprojekte, die ich entwickelt hatte, neigten dazu, Grenzen mit sehr fokussierten Modellen zu haben. Das war meist das Ergebnis unserer Programmierpraxis und der komponentenbasierten Technologien, die wir verwendeten. Es war schon sinnvoll, dass wir verschiedene Softwareteile auseinanderbrachen, aber wir taten das nicht wegen der Businesssprache. Die Idee, dass verschiedene Businesstreiber verschiedene Sprachen innerhalb verschiedener Grenzen benutzten, hat mein Denken beflügelt.

Nachdem ich Erfahrungen mit den Mustern von DDD gesammelt hatte, sprach ich auf Meet-ups und lokalen Konferenzen darüber. Meine Vorträge zu dem Thema hatten jedoch kein großes Publikum – im Gegensatz zu meinen Talks über Datenbanktechnologien. Angesichts meiner aufrichtigen Bemühungen, den Leuten zu helfen, konnte ich nicht verstehen, wie etwas so Richtiges von den meisten Entwicklern ignoriert oder gar abgelehnt werden konnte. Im Wesentlichen gab mir mein neu gefundener Resonanzboden Sicherheit, dass ich mit meinen eigenen Erfahrungen über Design auf dem rechten Weg war. Aber die Einstellung der Entwickler um mich herum änderte sich nicht. Ich konnte auf dieses brillante blaue Buch verweisen, aber mir gelang es nicht, mit meinen eigenen Ideen und Aspirationen Eindruck zu hinterlassen.

E: Mit deinem Buch „Implementing Domain-Driven Design“ hast du einen wichtigen Beitrag zur Verbreitung von DDD geleistet. Was war dabei deine Motivation? Welche Ideen wolltest du hinzufügen, ausarbeiten, spezifizieren?

Vernon: Da ich das tun wollte, wovon ich überzeugt war, hatte ich eine Menge Arbeit vor mir. Denn DDD kann man nur anwenden, wenn auch andere es anwenden. Das bedeutete, dass ich andere davon überzeugen musste. Seitdem ich vor 36 Jahren gelernt habe, Software zu entwickeln, hat mir harte Arbeit nie Angst gemacht oder mich übermäßig erschöpft. Softwareentwicklung ist kreativ. Schaffen ist lohnend. Das Schaffen setzt in meinem Gehirn Chemikalien frei, die eine unglaublich positive intellektuelle und emotionale Befriedigung bringen. Es ist nicht schwer für mich, das zu tun. Es ist schwer für mich, es nicht zu tun. Ich hoffe, dass andere dieses Gefühl genauso oft erreichen wie ich.

Mein Ansatz für das Buch war der folgende: Ich wollte nicht nur das Was zeigen, sondern vor allem das Wie. Erics Buch hinterließ bei denjenigen, die es lasen, zwar einen sehr starken Eindruck, dass DDD fantastisch ist. Doch sie fragten sich auch: „Wie kann ich diese fantastischen Ideen in meiner Welt umsetzen?“ Meine Erklärungen mussten also viel mehr Code enthalten und Beispiele verwenden, die Softwareentwickler leicht verstehen würden.

Mir fiel auch auf, dass es Bemühungen gegeben hatte, DDD mit C# und dem .NET Framework zu erklären. Aber es gab wenig bis gar nichts über die Verwendung von DDD in Java. Da Java die Sprache war, die ich am häufigsten in Projekten verwendete, empfand ich das als großes Defizit. Und weil J2EE meiner Meinung nach eine solche Katastrophe war, musste ich DDD auf dem Spring Framework zeigen. Spring hatte meiner Einschätzung nach J2EE bereits fast vollständig als brauchbare Spezifikation eliminiert. Es ergab also allein deshalb schon Sinn, DDD mit Spring statt mit einer anderen Technologie zu erklären, weil viele Java-Entwickler Spring bereits einsetzten. Trotzdem habe ich meine Leser bewusst nicht mit den Besonderheiten von Spring überfordert. Ich habe nicht mehr gezeigt, als dass DDD mit zeitgemäßen, populären Frameworks umgesetzt werden kann.

Darüber hinaus hatte ich genug von Erics Konferenzpräsentationen gesehen, um zu wissen, dass er sich wünschte, er hätte die strategischen Muster in den Vordergrund gestellt und nicht am Ende seines Buches platziert. Obwohl ich zustimme, dass die strategischen Muster eigentlich an den Anfang gehören, habe ich eine Theorie, warum es so vielleicht doch besser war. Da Softwareentwickler mehr von Technologien angezogen werden und die taktischen Muster näher an der Technologie sind, war Erics „Fehler“, die taktischen Muster vorn zu platzieren, eigentlich der Grund für die Anziehungskraft von DDD. Ich mag mich irren, aber ich glaube, dass Entwickler dazu neigen, die taktischen Muster schnell aufzunehmen, während sie mit den strategischen Mustern zu kämpfen haben. Wenn sie zuerst auf die Strategie gestoßen wären, hätten sie vielleicht aufgehört zu lesen.

Mit dieser Neigung der Entwickler im Hinterkopf entschied ich mich, die Situation eines Teams zu schildern, das die taktischen Muster von DDD verwendete, während es die strategischen ignorierte. Nachdem das Team in eine Sackgasse geraten war, zeigte ich, wie sie das Steuer herumreißen konnten, um in die richtige Richtung zu fahren. Das heißt, sie entdeckten den zweiten Teil von Erics Buch, setzten die strategischen Muster an die erste Stelle und zogen einen erheblichen Nutzen daraus.

E: Die Grundprinzipien von DDD sind mittlerweile vielen bekannt. Aber ihre Umsetzung in die Praxis ist alles andere als trivial. Hast du hier einen Tipp für die Leser? Wie kann man mit DDD in einem Projekt beginnen?

Vernon: Ich habe erkannt, dass den meisten Softwareentwicklern und Teams einige sehr wichtige Kenntnisse fehlen, die sie sich erst aneignen müssen, bevor sie überhaupt daran denken sollten, DDD einzusetzen. Ich sage gerne, dass Teams zuerst drei wichtige Dinge verstehen müssen:

  1. Conway’s Law

  2. Conway’s Law

  3. Modularisierung

Nein, es ist kein Fehler, dass hier zwei Mal Conway’s Law steht. Ich will damit unterstreichen, dass Teams im Allgemeinen nicht verstehen, dass die Struktur ihrer Organisation sowie der Einfluss dieser Struktur auf die Art und Weise der Kommunikation das Ergebnis der von ihnen gelieferten Software bestimmt. Wenn die Teams nicht miteinander reden, werden sie eine Menge widersprüchlicher und verwirrender Bedeutungen zwischen den Komponenten eines bestimmten Softwaresystems haben. Wenn die Teams entgegen den Softwarezielen strukturiert sind, werden die Ziele nicht vollständig erreicht werden. Man kann auch erwarten, dass die Software die Fähigkeit eines Teams verstärkt, klar und tiefgehend zu kommunizieren.

Nachdem man das verstanden hat, kann man darüber nachdenken, wie die Kommunikation eines Teams die Modularisierung der Softwarekomponenten beeinflussen sollte. Aber man muss sich dieses Ziel bewusst machen.

Wenn man feststellt, dass das Thema einer Kommunikation sich auf verschiedene Kontexte bezieht, ist das ein starker Hinweis darauf, dass man die Kommunikation in separate Modelle bzw. Module aufteilen sollte. Wenn die einzelnen Modelle, jedes davon in separaten Modulen, miteinander zusammenarbeiten oder sich integrieren, sollte der Austausch zwischen den Modulen möglichst lose gekoppelt sein.

Diese „drei“ kritischen Punkte sind die Grundlagen von DDD. Ich habe gerade das Konzept einer Ubiquitous Language eingeführt, die das Ergebnis von Teamkommunikation ist. Ich habe das Konzept der Bounded Contexts erklärt, das Modularisierung um die spezifischen Arten von Gesprächen herum bedeutet. Und ich habe das Context Mapping zwischen den modularisierten Modellen erwähnt, die zusammenarbeiten und sich integrieren müssen. Nun gilt es, zu bestimmen, welche Context-Mapping-Muster zwischen den modulbasierten Bounded Contexts verwendet werden sollen und welche taktischen Muster innerhalb jedes modulbasierten Bounded Context sinnvoll sind.

Das wird nicht einfach sein, aber man kann versuchen, es einfach zu halten. Mein Rat an dieser Stelle ist es, das Netzwerk zwischen den Modulen nicht zu früh oder sogar überhaupt nicht aufzubauen. Die Module können zumindest für eine Weile in einer einzigen (J) VM gehostet werden. Dadurch wird verteiltes Rechnen schon früh aus der Gleichung genommen. Verteiltes Rechnen bringt alle Arten von unnötiger Komplexität mit sich. Schon von Beginn an kommt es viel eher darauf an, die Businessanforderungen zu verstehen und sie in Softwaremodellen umzusetzen.

E: Wenn wir uns die heutigen Diskussionen über Softwarearchitektur ansehen, ist DDD immer noch sehr relevant. Im Rahmen der Microservices-Debatte erleben wir sogar so etwas wie ein Revival. Was hältst du von Microservices? Sind Microservices die Essenz dessen, was DDD ausmacht?

Vernon: Mein Rat ist, wie oben teilweise schon ausgeführt, zunächst die Modularisierung innerhalb einer einzigen (J)VM durchzuführen. Erstellt genau dieselben Context-Mapping-Verbindungen zwischen den Modulen, aber ohne das Netzwerk. Überprüft dann, ob es signifikante Team- oder Technologieanforderungen gibt, die dafürsprechen, die Module in separate (J)VMs oder auf separate Nodes aufzuteilen. Relevante Fragen könnten sein:

  1. Gibt es bei den verschiedenen Modulen eine unterschiedliche Änderungsrate, die CI/CD-Reibungen verursacht?

  2. Sollte ein einzelnes Team aufgrund der Kommunikationsanforderungen und Ziele in zwei oder mehr Teams aufgeteilt werden?

  3. Benötigt ein einzelnes Modul oder ein kleinerer Teil eines einzelnen Moduls eine höhere Skalierung als andere Module?

  4. Benötigt ein einzelnes Modul oder ein kleinerer Teil eines einzelnen Moduls einen größeren Durchsatz oder hat andere Performanceanforderungen als andere Module?

Wenn ja, hat man einen Grund, eins oder mehrere der Module aus dem einen (J)VM Deployment herauszunehmen. Angenommen, der modulare Monolith, den wir anfangs erstellt haben, hat fünf Hauptmodule. Wenn man es rechtfertigen kann, alle fünf Module in separate (J)VMs und Deployment-Einheiten zu zerlegen, haben wir fünf Microservices, die sich eins zu eins an Bounded Contexts ausrichten. Da Bounded Contexts dazu tendieren, aufgrund des Fokus einer gegebenen Ubiquitous Language relativ klein zu sein, ist ein Bounded Context als Microservice ein gutes erstes Ziel.

Wenn einige der Anforderungen, wie z. B. die Punkte 3 und 4 oben, eine weitere Zerlegung erfordern, sollte man sich im Klaren darüber sein, dass diese Anforderungen keine fachlichen, sondern technische sind. Die Bounded Contexts ändern sich dann nicht, auch wenn die Deployment-Einheiten sich ändern.

E: Welcher Aspekt von DDD wird heute in der Praxis am meisten vernachlässigt?

Vernon: Die Kommunikation zwischen Entwicklern und Businessstakeholdern. DDD bezieht sich auf die Businessstakeholder, die als Domänenexperten ein signifikantes Verständnis für die Ziele des Systems haben. Ich denke, dass diese unzureichende Kommunikation verschiedene Gründe hat:

  1. Es ist manchmal schwierig, zu erkennen, wer tatsächlich ein Experte ist. Man muss auch bedenken, dass einige Bereiche so neu sind, dass es möglicherweise keine echten Experten gibt. Die Fachexperten müssen im laufenden Prozess erst durch eine Investition in kommunikative Innovation aufgebaut werden.

  2. Es gibt Fachexperten, die es ablehnen, sich zu engagieren, oder es schwierig finden, die notwendige Zeit dafür aufzubringen. In diesem Fall muss man einen Weg finden, die nötige Beteiligung der Fachexperten zu beschleunigen. Man sollte auch keine Zeit damit verschwenden, die Fachexperten in technologischen Fragen oder ähnlichem zu korrigieren. Am besten man arbeitet mit dem, was sie zu geben haben.

  3. Es mag einige überraschen, aber meine Beobachtung ist, dass es oft auch die Architekten und Entwickler sind, die nicht mit Businessexperten oder sogar mit anderen Entwicklern kommunizieren wollen. Das ist in der Regel auf einen introvertierten Charakter oder auf Vorurteile gegenüber nicht technisch orientierten Geschäftsleuten zurückzuführen. Oder einfach mangelnde emotionale Intelligenz, die u. a. beinhaltet, freundlich und konstruktiv mit anderen Menschen zu sprechen.

Wie ich bereits sagte: Wer sich der Auswirkungen von Conway’s Law auf seine Projekte nicht bewusst ist, wird mit ungenügenden Ergebnissen rechnen müssen.

E: Du beschäftigst dich momentan stark mit reaktiver Programmierung. Was ist die Beziehung zwischen Reactive und DDD? Gibt es hier eine engere Verbindung?

Vernon: Ja, ich denke schon, dass es da eine engere Verbindung gibt. Für mich persönlich finde ich, dass der Einsatz des Aktorenmodells eine großartige Möglichkeit ist, um über die Lösung von Geschäftsproblemen nachzudenken. Jeder Aktor, der im Wesentlichen ja ein Objekt ist, hat ein Kommunikationsprotokoll, das sich sehr eng an einen Teil der Ubiquitous Language eines Teams in einem Bounded Context anlehnt. Auch hier wird die Sprache mit Hilfe expliziter Kommunikation entwickelt, und man entwirft die Aktorenobjekte so, dass sie in derselben Sprache miteinander sprechen.

Das Aktorenmodell bietet auch einige sehr vorteilhafte technische Features, die moderne Hardwarearchitekturen und Cloudinfrastrukturen ansprechen. Aktoren kommunizieren asynchron miteinander, indem sie Nachrichten senden. Das unterscheidet sie von typischen Objekten, die direkte Methodenaufrufe verwenden, die den Aufrufer blockieren. Bei der Verwendung unserer Plattform vlingo etwa fühlt sich der technische Kommunikationsstil wie ein gewöhnlicher Methodenaufruf an, aber unter der Haube funktioniert er als asynchrone Message.

Der asynchrone Nachrichtenversand ist für die heutigen Hardwarearchitekturen extrem wichtig, da er die Verwendung aller Kerne und Hyperthreads in einer nichtblockierenden Weise ermöglicht. Insgesamt ist der Durchsatz der gesamten Lösung effizienter als bei blockierenden direkten Methodenaufrufen. Das Ergebnis ist auch höhere Skalierbarkeit in einer gegebenen (J) VM, in einem Cluster und im gesamten System.

Die Art und Weise, wie die Nachrichten an die Aktoren gesendet werden, d. h. eine nach der anderen der Reihenfolge nach, sorgt für perfekte Transaktionsgrenzen, bei denen es möglicherweise nie zu Datenbank-Races kommt, die Datenkonflikte und Transaktionsausfälle verursachen.

Potentiell können diese aktorenbasierten Objekte für lange Zeit im Cache gehalten werden, solange sie heiß bleiben, d. h. häufig verwendet werden. Wenn ein selten verwendeter Aktor aus dem Speicher entfernt wird, wird sein Zustand sicher persistiert, so dass er schnell wiederhergestellt werden kann, wenn die nächste Nachricht eintrifft.

Man muss verstehen, dass solche Möglichkeiten den älteren, containerbasierten Legacy Frameworks, die die meisten Entwickler seit Jahren verwenden, nicht zur Verfügung stehen. Legacy Frameworks leiden unter dem Dilemma des Innovators und werden sich nie vollständig in das verwandeln können, was in der Zukunft der Softwareentwicklung benötigt wird.

Unsere vlingo-Plattform hat kürzlich das erste Major-Release 1.0.0 GA erreicht. Die Plattform ist durch und durch reaktiv, einfach zu erlernen und einzusetzen. Mehr dazu erzähle ich in einem ausführlichen Artikel in einer der kommenden Ausgaben des Entwickler Magazins.

E: Welchen Aspekt in der aktuellen Diskussion über Softwarearchitektur findest du derzeit besonders spannend?

Vernon: Meine Interessen liegen im Bereich Messaging, und zwar sowohl für kleine als auch für hochskalierende Systeme. Alan Kay, der Schöpfer des Begriffs Objektorientierung und der Sprache Smalltalk, sagte einmal, dass das Interessante an Objekten die Messages zwischen ihnen sei. Alan Kay betrachtete Objekte immer als Nachrichtenprozessoren, und genauso wurde Smalltalk entworfen. Jedes in der (S)VM lebende Smalltalk-Objekt ist ein Nachrichtenprozessor.

Ich bin persönlich in zwei Firmen aktiv: Die eine ist Kalele und die andere Vlingo. Der Name Kalele ist das hawaiianische Wort für Nachrichtenübermittlung. Beim Namen Vlingo geht es um eine Ubiquitous Language für aktorenbasierte Objekte.

Messaging ist eine exzellente Technik zur Entkopplung von Softwarekomponenten, bei der das Protokoll die Nachrichten definiert, die gesendet und empfangen werden können, und die sich an der Sprache eines DDD-Teams orientieren. Menschen kommunizieren mit Hilfe von Nachrichten, und die Nachahmung menschlicher Kommunikation mittels aktorenbasierter Objekte ist eine gute Möglichkeit, DDD effektiv zu nutzen.

E: Vielen Dank für dieses Interview!

Die Fragen stellte Hartmut Schlosser

vernon_vaughn_sw.tif_fmt1.jpgVaughn Vernon ist Gründer, Hauptarchitekt und Entwickler von vlingo/PLATFORM bei Kalele. Als Softwareentwickler und Architekt mit mehr als 35 Jahren Erfahrung in einer Vielzahl von Geschäftsbereichen ist Vaughn ein führender Experte für Domain-driven Design (DDD) und ein Verfechter von Einfachheit und reaktiven Systemen. Vaughn ist der Autor von drei Büchern: „Implementing Domain-Driven Design“, „Domain-Driven Design Distilled“ und „Reactive Messaging Patterns with the Actor Model“, alle erschienen bei Addison-Wesley.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -