Verlag

Software & Support Media GmbH

Anschrift der Redaktion:

JAXenterSoftware & Support Media GmbHSchwedlerstraße 8D-60314 Frankfurt am MainTel. +49 (0) 69 630089-0Fax. +49 (0) 69 630089-89redaktion@jaxenter.dewww.jaxenter.de

Chefredakteur: Sebastian Meyen

Redaktion: Hartmut Schlosser, Melanie Feldmann, KyprianiSinaris, Dominik Mohilo, Gabriela Motroc

Chefin vom Dienst/Leitung Schlussredaktion: Nicole Bechtel

Schlussredaktion: Jennifer Diener

Leitung Grafik Produktion: Jens Mainz

Layout: Dominique Kalbassi

Titel: ©istockphoto.com/liangpv

Software & Support Media GmbHAnika StockTel.: +49 (0) 69 630089-22Fax: +49 (0) 69 630089-89 anika.stock@sandsmedia.comEs gilt die Anzeigenpreisliste Mediadaten 2016© Software & Support Media GmbH

Alle Rechte, auch für Übersetzungen, sind vorbehalten.Reproduktionen jeglicher Art (Fotokopie, Nachdruck, Mikrofilmoder Erfassung auf elektronischen Datenträgern) nur mitschriftlicher Genehmigung des Verlages. Eine Haftung für dieRichtigkeit der Veröffentlichungen kann trotz Prüfung durch dieRedaktion vom Herausgeber nicht übernommen werden.Honorierte Artikel gehen in das Verfügungsrecht des Verlagsüber. Mit der Übergabe der Manuskripte und Abbildungen an denVerlag erteilt der Verfasser dem Herausgeber das

Exklusivitätsrecht zur Veröffentlichung. Für unverlangteingeschickte Manuskripte, Fotos und Abbildungen keineGewähr. JavaTM ist ein eingetragenes Warenzeichen von Oracleund/oder ihren Tochtergesellschaften.

Liebe Leserinnen undLeser,Domain-driven Design – kurz DDD – erfährt inder aktuellen Diskussion umSoftwarearchitektur eine hoheAufmerksamkeit. Das Anfang der 2000er

geprägte Konzept gilt insbesondere als eine der Grundlagen-Theorien für Microservices-Architekturen. Grund genug, dasThema in einem Dossier genauer zu beleuchten:

Willkommen zum JAXenter-Dossier DDD!

Neben einführenden Artikeln zum Domain-driven Design lassenwir wichtige Gründerväter zu Wort kommen: Eric Evans, VaughnVernon und Jimmy Nilsson. Außerdem geben Experten ihrPraxiswissen weiter und zeigen auf, warum DDD heute sorelevant ist und wie Sie in Ihren Software-Architekturen von denKonzepten des Domain-driven Design profitieren!

Viele inspirierende Momente bei der Lektüre wünscht,

Hartmut SchlosserRedakteur JAXenter

www.jaxenter.deTwitter: @JAXenter

Folgender Inhalt erwartet Sie:„Microservices können Teams dabei helfen, DDD zupraktizieren“ – Interview mit Eric EvansEinführung in die Konzepte des Domain-driven Design –Artikel von Martin Kernland und Adrian Gygax„Man braucht einen Tag, um von DDD zu profitieren, aberein ganzes Leben, um es zu meistern“ – Interview mitJimmy NilssonReactive Microservices mit Scala und Akka – Artikel von

Vaughn Vernon„Ich bin keinesfalls der Meinung, dass man immerMicroservices einsetzen sollte“ – Interview mit StefanTilkovMicroservices lieben Domain-driven Design – Artikel vonMichael PlödDomain-driven Design im Experten-Check – Wie kann DDDin die Praxis umgesetzt werden?

Interview mit Eric Evans, dem Vater desDomain-driven Design

„Microservices können Teamsdabei helfen, DDD zupraktizieren“Eric Evans hat mit seinem Buch “Domain-driven Design:Tackling Complexity in the Heart of Software” die Methode desDomain-driven Design entscheidend geprägt. Wir haben unsmit ihm über seine Motivation für DDD und denZusammenhang zwischen Domain-driven Design undMicroservices unterhalten.JAXenter: Hallo Eric. Mit deinem Buch “Domain-driven Design”hast du 2003 einen IT-Klassiker geschrieben. Was war dabeideine Kernidee? Worum geht es dir beim Konzept des Domain-driven Design?Eric Evans: Der entscheidende Punkt, um den es mir geht, istauch der Grund, warum das Konzept “Domain-driven Design”heißt: Wenn wir Software entwickeln, sollte unser Fokus nichtprimär auf den Technologien liegen, die wir verwenden.Stattdessen sollte sich unser Hauptaugenmerk auf die

geschäftliche Seite richten, also auf den fachlichen Bereich, denwir mit unserer Software unterstützen wollen – kurz: auf dieDomäne. Das ist es, was ich mit Domain-driven Design meinte.

Insbesondere wollen wir das dadurch erreichen, indem wirModelle dieser Domäne entwickeln und unsere Software diesenModellen anpassen. Es handelt sich also auch um einen vielstärker konzeptuell ausgerichteten Design-Prozess als gemeinhinüblich.

JAXenter: Domain-driven Design erlebt gerade so etwas wieein Revival. Insbesondere werden die Prinzipien des DDDimmer wieder in den Diskussionen um Microservice-Architekturen genannt. Inwiefern hilft DDD bei Microservices?Eric Evans: Anfangs interessierte ich mich für das ThemaMicroservices, weil ich meinte, Microservices können Teamsdabei helfen, DDD zu praktizieren. Mein Ansatz war also genauanders herum.

Doch wie auch immer: Als ich zum ersten Mal von Microserviceshörte, dachte ich sofort, dass wir diese Idee aufnehmen sollten.Warum? Nun, eines der größten Probleme beim Modellieren ist,dass man sich immer in einem großen System befindet, in demviele Leute viele unterschiedliche Dinge tun. Auf konzeptuellerEbene hat man es also mit einer unberechenbaren,unbeständigen Umgebung zu tun. Das Ziel besteht deshalb darin,beständige Konzepte zu finden und ein Modell zu schaffen, dasstabile Beziehungen enthält und nicht durch die vielen Dinge, diees integriert muss, in 1000 Stücke zerfällt.

Als ich von Microservices hörte, dachte ich, wir solltendiese Idee aufnehmen.

Man stelle sich einmal vor, man würde ein Kartenhaus in derMitte eines belebten Kinderspielplatzes errichten. Nun, das Hauswürde nicht lange stehen bleiben. Die Idee der Microservices istdeshalb, kleine, abgeschottete Bereiche zu schaffen, in denenman tatsächlich Kartenhäuser aufstellen und dafür sorgenkönnte, dass diese nicht umstürzen. Nicht alle Modelle müssen sobeständig sein, aber manche eben doch.

Obwohl mich neue Technologien für Service-Interfaces als solche

schon interessieren, ist es nicht so sehr der technologischeAspekt, der mich an Microservices reizt. Es geht mir mehr umden Ansatz, Dinge zu isolieren und autonom zu halten, nach demMotto: Wir brauchen keine übergreifende Datenbank, wir stützenuns nicht auf eine geteilte Codebasis, wir nutzen keingemeinsames Deployment, unser Team trifft seine eigenenEntscheidungen.

Dieser Ansatz der Isolierung und der Autonomie erlaubt die Artund Weise der Modellierung, die uns auch beim DDDvorschwebt.

JAXenter: Die Metapher des Kartenhauses deutet ja auf einegewisse Fragilität hin. Nun sieht die Microservice-Idee vor,dass unterschiedliche Teams autonom ihre Software-Einheitenbauen. Läuft man damit nicht Gefahr, dass Teile des Teamsund damit der Gesamtarchitektur fragil werden?Eric Evans: Natürlich ist die Metapher des Kartenhauses einwenig schief, weil man dabei etwas im Kopf hat, das zuzerbrechlich ist, um zu überleben. Die meisten Modelle müssennicht so sein – vielleicht kann man sich auch Bauklötze alsMetapher vorstellen. Aber auch diese werden nicht stehenbleiben, wenn man sie inmitten eines Kinderspielplatzesaufstapelt, wo alle herumrennen.

Das einzige, was in solchen Umgebungen Bestand haben wird,sich Sachen, die flach auf dem Boden liegen oder einfache Dinge,die dafür ausgelegt sind, von einem Ort an den anderen bewegtzu werden. Wenn wir uns daran orientieren, dann ist es keinWunder, dass die Systeme, die wir designen, so aussehen, wie sieaussehen.

Wenn wir Dinge umsetzen wollen, müssen wir Umgebungenschaffen, in denen diese Dinge auch funktionieren können.

Worauf ich hinauswill: Wir haben es in der Software-Entwicklungmit sehr chaotischen Umgebungen zu tun, in denen wir großeSysteme entwickeln sollen, und wir müssen diesen Umstand vonvorneherein mit in den Design-Prozess einbeziehen. Wenn wirDinge umsetzen wollen, die einigermaßen komplex undbeständig sein sollen, dann müssen wir Umgebungen schaffen, in

denen diese Dinge auch funktionieren können. Das müssen keinegroßen Umgebung sein – aber sie müssen klare Grenzenaufweisen. Wir nennen das Bounded Context. Nicht alles benötigtein solches Maß an Schutz, aber manche Dinge schon.

In einem System werden wir dann mehrere solche abgegrenztenKontexte haben. Und es stimmt, dass nicht alle Teams diese Ideegleich gut umsetzen werden. Doch eine Sache, die ich an derMicroservices-Debatte mag, ist, dass die Tatsache mitberücksichtigt wird, dass einige Dinge schief gehen können. Auchauf konzeptueller Design-Ebene kann einiges schief gehen. Undwir möchten ein Gesamtsystem, das robust genug ist, um sagenzu können: Selbst wenn ein gewisses Team einige sehr schlechteDesign-Entscheidungen getroffen hat, ruiniert es nicht dasDesign, das ein anderes Team gewählt hat.

Genauso ein System brauchen wir – andernfalls werden wirdganz einfach nirgends ein gutes Design vorfinden. Denn das istdas Problem bei monolithischen Systemen: Es gibt dort eigentlichnirgends ein gutes Design, weil es nicht diese geradebeschriebene Art von Grenzziehung gibt. Sobald Leute eineschlechte Entscheidung treffen, breiten sich die Konsequenzendieser Entscheidungen aus – und allmählich hat man einengroßen Haufen Matsch vor sich, wie wir es manchmal liebevollnennen.

JAXenter: Vielen Dank für dieses Interview!Das Interview wurde von Coman Hamilton auf der JAX 2015geführt.

Eric Evans ist Autor des Buches “Domain-driven Design:Tackling Complexity in the Heart of Software” und einerder Vordenker für Software Design, Domain-drivenDesign und Domain Modeling. Eric Evans ist einer derHauptkontributoren des Portals dddcommunity.org und

Sprecher auf internationalen Fachkonferezen. Auf seinem Bloghttp://domainlanguage.com/ veröffentlicht er Beiträge zu Domain-Driven Design mit dem Fokus auf strategischem Design.

DDD: Amazing!

Einführung in die Konzepte desDomain-driven DesignDomain-driven Design – kurz DDD – erfährt in der aktuellenDiskussion um Softwarearchitektur eine hoheAufmerksamkeit. Das Anfang der 2000er geprägte Konzept giltinsbesondere als eine der Grundlagen-Theorien fürMicroservices-Architekturen. Grund genug, dem Thema ineinem Dossier genauer auf den Grund gehen. Zur Einführung indie Konzepte von Domain-driven Design präsentieren wir denArtikel “DDD Amazing!”, in dem die fiktive Firma Amazine ihreSystemlandschaft mit Hilfe von DDD neu ordnet.Martin Kernland und Adrian Gygax

DDD: Amazing!Die fiktive Firma Amazine hat ein Problem: Das Geschäft wirdgebremst durch die IT-Systemlandschaft, die auf änderndeAnforderungen nicht rasch genug reagieren kann. Lernen Siezusammen mit Amazine, wie die Anwendung von Domain-drivenDesign eine Systemlandschaft in Schwung bringt.

Einführung in die Konzepte von Domain-driven Design

Stellen Sie sich vor, Sie müssten ein komplexes Softwaresystemoder sogar eine komplexe Applikationssystemlandschaft flexiblerund robuster machen. Egal welche Rolle Sie haben, sei es alsProjektleiter, Softwarearchitekt, Businessanalyst oder gar CIO, fürdiese Aufgabe benötigen Sie unterschiedliche Leute mitunterschiedlichen Fähigkeiten. In diesem Artikel werden einigeHerausforderungen aus Sicht des Softwarearchitektengeschildert. Die Rolle des Architekten wird je nach Unternehmenunterschiedlich ausgelegt. Wir möchten hier eine möglichstganzheitliche Betrachtung dieser Rolle aufzeigen und auf dreiunterschiedliche Ebenen der Architektur eingehen: dieUnternehmensarchitektur, die Systemarchitektur und dieImplementationsebene. Dazu bringen wir einige Aspekte vonDomain-driven Design ein und zeigen auf, wie man damitArchitekturen robuster und gleichzeitig flexibler machen kannund zwar auf allen drei erwähnten Ebenen.

Domain-driven Design (DDD) ist einerseits eine Denk- undArbeitshaltung eines Architekten, andererseits eine Sammlungvon Methoden, welche die Bedeutung der Domäne und dessenModellierung ins Zentrum der Architekturarbeiten stellt. DieDomäne ist das Anwendungsgebiet, resp. der Einsatzbereich derSoftware, meist also die Fachlichkeit und die Fachlogik einesGeschäftsfelds. Das Domänenmodell ist die Abbildung der Essenzder Domäne mit objektorientierten Konzepten. Bei DDD gehtman davon aus, dass der größte Teil der Komplexität einerSoftware nicht in der technischen Umsetzung liegt, sondern inder Modellierung der Domäne. Domain-driven Design wurdedurch das gleichnamige Buch von Eric Evans [1] einem breiterenPublikum bekannt gemacht.

Bevor wir die besagte komplexe Systemlandschaft und derenSysteme robuster und flexibler machen, definieren wir, wie wirRobustheit und Flexibilität im Rahmen dieses Artikels verstehen:Wir definieren Robustheit als die Eigenschaft der Software, auchunter ungünstigen Bedingungen noch zuverlässig zufunktionieren. Dies erreicht man z. B. durch eine Reduktion derFehlerrate oder auch durch eine gute Strukturierung derKomplexität der Software. Flexibilität ist die Eigenschaft derSoftware, einfach an geänderte Anforderungen angepasst werdenzu können. Dies wäre z. B. die Änderbarkeit oder die

Erweiterbarkeit der Software.

DDD auf Ebene UnternehmensarchitekturDer Unternehmensarchitekt fokussiert sich auf die Applikations-und Systemlandschaft des Unternehmens. Dabei werdenZuständigkeiten der Applikationen geschnitten, Schnittstellenvereinfacht und Technologien harmonisiert. Hierzu verwendendie Unternehmensarchitekten meist ein Framework wie TOGAF[2] oder Zachmann [3], um die Komplexität der Systemlandschaftzu strukturieren und somit beherrschbar zu machen.

DDD geht einen leicht anderen Weg und bietet alternativeMethoden an, um z. B. auch implizite Beziehungen undInformationen sichtbar zu machen. Eine mächtige Methode istd i e Context Map, mit der man die Kontexte, in denenDomänenmodelle Gültigkeit haben, darstellen kann. Nehmen wirdas folgende Beispiel, das uns in diesem Artikel begleiten wird.Die Systemlandschaft der fiktiven Firma Amazine GmbH, einekleine Onlinebuchhandlung, ist (wie man oft sagt) „historischgewachsen“: Bevor die Buchhandlung online ging, hatte man nurein CRM als Kundenverwaltung, eine Lagerverwaltung und eineBuchhaltung. Dann kamen immer mehr Systeme hinzu. Um dieSystemlandschaft nun robuster und flexibler zu gestalten, lädtder Unternehmensarchitekt der Amazine einen DDD-Berater ein,ihn tatkräftig dabei zu unterstützen. Als Erstes schafft sich derDDD-Berater einen Überblick mittels der Context-Map-Methode.Dabei befragt er einige Entwickler in Interviews zur Situation. DieInformationen stellt er in einer informalen Karte auf einem Flip-Chart zusammen. In Abbildung 1 wurde die heutige Situation inschwarzer Farbe als Context Map abgebildet.

Abb. 1: Context Map Amazine heute

Die Systeme sind als Kreise eingezeichnet. Auffällig ist dasOnlineshopsystem, von dem mehrere Beziehungen ausgehen. Ineinigen Fällen ist ein „Up“ oder „Down“ erwähnt, dies steht fürUpstream und entsprechend Downstream. Hiermit wird dieMachthierarchie zwischen den Entwicklungsteams dieserSysteme ausgedrückt, wobei das Team des Systems, dasDownstream steht, die Bedingungen des Upstreamsystemsakzeptieren muss. Sehen wir uns gleich ein Beispiel in derAbbildung 1 an: Der Onlineshop steht Downstream zurLagerverwaltung, die eine typische Legacy-Applikation ist. DieAnbindung an dieses System war nicht einfach. Es gibt keineDokumentation zu den Schnittstellen und das Team derLagerverwaltung gibt nur spärlich Informationen preis. Nur miteinigem Trial und Error konnte die Schnittstelle erstellt werden.Wenn sich die Schnittstelle ändert, muss der Shop nachziehen.Wünsche an die Schnittstelle wurden bisher nie umgesetzt.Interne Eskalationen haben noch nichts bewirkt. DasManagement weiß genau, dass es keine anderen Experten fürdieses Legacy-System gibt, und man möchte daher das Team derLagerverwaltung nicht verärgern. Der Shop steht also klarDownstream zum Lagerverwaltungssystem.

Ein anderes System, das Downstream steht, ist derProduktekatalog. Dieser erhält die Datensätze zu den

verfügbaren Büchern der einzelnen Verlage. Als man denProduktekatalog baute, hat man sich stark an Verlag A orientiertund dessen Buchmodell übernommen. Die Daten der anderenVerlage werden in das Modell des Verlags A übernommen. Leiderhat Verlag A schon zwei Mal das Modell geändert und jedes Malmusste der Produktekatalog nachziehen und angepasst werden.Der Produktekatalog steht also Downstream zum System desVerlags A. Bei dieser Beziehung sieht man auch den BoundedContext des Buchmodells, dies ist die gestrichelte Linie, die dieKontextgrenze und somit den Gültigkeitsbereich desBuchmodells angibt. Innerhalb dieses Bereichs verwendet mandas gleiche Buchmodell, außerhalb dieses Bereichs kennt mandieses Modell nicht. Ein interessanter Bounded Context wirdbeim CRM (Kundenverwaltung), beim Shop und demEmpfehlungssystem ersichtlich: Das Modell des Kunden wurdebeim Bau des Shops vom CRM-System übernommen. Wieder istder Shop Downstream zu einem System, zum CRM. DasEmpfehlungssystem ist das Resultat einer Diplomarbeit einesJuniorentwicklers, der heute die meiste Zeit am Shopsystemarbeitet und nebenbei das Empfehlungssystem wartet. Umschnell ein Resultat zu bekommen, hat er das Kundenmodell desShops übernommen. Immer wenn der Entwickler heuteAnpassungen machen muss, muss er aufpassen, keineNebeneffekte zu erzeugen. Nur gut, dass er auch am Shopsystemarbeitet und dieses System gut genug kennt. Die Kollegen desKreditkartensystemteams haben einen Adapter gegenüber denFremdsystemen gebaut, der sie vor Änderungen schützt. In derSprache des DDD nennt man dies einen Anti-Corruption Layer(ACL), in Abbildung 1 als Rechteck eingezeichnet. Seit sie die ACLhaben, ist ihr Kreditkartensystem unangetastet. Klar müssen siemanchmal einen ACL an Änderungen anpassen, aber das interneModell ihres Systems muss nicht angefasst werden.

Dem aufmerksamen Leser sind wahrscheinlich die Schwächendieser Systemlandschaft aus der Beschreibung aufgefallen. InAbbildung 2 sind einige Lösungsvorschläge des DDD-Beraters inroter Farbe dargestellt.

Abb. 2: Context Map mit Vorschlag des DDD-Beraters

Das Shopteam hat nun genug vom Lagerverwaltungssystem undbaut einen ACL ein. Dadurch schützen sie sich vor zukünftigenVeränderungen der Modelle und der Schnittstellen. In einerspäteren Version der Versandapplikation ist eine Schnittstellezum Lagerverwaltungssystem geplant. Aus diesem Grund bautdas Team den ACL zu einem Adaptersystem aus, sodass dieKollegen der Versandapplikation dieses Adaptersystem als eineangenehmere Schnittstelle (z. B. eine sauber umgesetzte REST-Schnittstelle) nutzen können. Der Shop und das Versandsystemsind nun Upstream gegenüber dem Adapter. Außerdem bietet dasAdaptersystem nun einen sanften Start, damit mittelfristig dieLegacy-Lagerverwaltung abgelöst werden kann.

Um den Shop und die Empfehlungs-Engine robuster bezüglichfremden Modelländerungen zu machen, entscheidet dasShopteam, den Bounded Context des Kundenmodells so zu legen,dass sowohl der Shop als auch die Empfehlungs-Engine inseparaten Kontexten liegen und somit beide ihr eigenesKundenmodell pflegen können. Gemeinsam ist nun nur noch dieKundennummer als Identifikation des Kunden. Der Shop schütztsich dabei mit ACLs. Mit der gleichen Maßnahme wird derProduktekatalog gegenüber Änderungen von externen Systemengeschützt.

Der ACL wird nun so umgesetzt, dass die Systeme auch technisch

entkoppelt werden, damit im Fehlerfall des einen Systems dasandere System nicht beeinträchtigt wird. Dies kann z. B. mitasynchronem Messaging und explizitenFehlerbehandlungsroutinen umgesetzt werden. Somit wird dieSystemlandschaft noch robuster als z. B. bei eng gekoppeltenSystemen.

Sobald ein konsistentes Domänenmodell vorliegt, ist man alsUnternehmensarchitekt oft geneigt, verleitet oder gar besessen,dieses Modell über eine ganze Systemlandschaft hinwegkonsistent zu halten. Dies ist jedoch kaum möglich oderzumindest nicht kosteneffektiv. Oft ist es sogar kaum möglich,zwischen zwei Teams, die an der gleichen Applikation arbeiten,ein gemeinsames Modell zu pflegen. Schlimmer noch, die Teamsdenken und glauben, dass sie das gleiche Modell benutzen, in denDetails geht das Verständnis jedoch auseinander. Ein berühmtesBeispiel hierzu ist der Verlust der Mars-Climate-Orbiter-Sonde [4]:Weil zwei Teams je Logik gebaut haben, die einen Wert mitunterschiedlichen Einheiten ausgewertet hat, stürzte die Sondeab. Besser ist es, ganz bewusst einen Bounded Context zuerstellen, in dem das Domänenmodell seine Gültigkeit hat, umdort die Komplexität der Domäne beherrschbar zu machen.Schafft man es, in einer Gruppe innerhalb einer Kontextgrenzeoder sogar zwischen Gruppen eine gemeinsame Sprache zusprechen, nennt Evans dies Ubiquituous Language. EineUbiquituous Language liegt vor, wenn alle Beteiligten dieDomäne mit den gleichen Wörtern beschreiben und daher alledasselbe darunter verstehen. Diese einheitliche Sprache istbesonders nützlich, nein gar äußerst wichtig, zwischen denDomänenexperten und des umsetzenden Teams. Besteht keinegemeinsame Sprache, wird die Software viele Fehler aufweisen,unnötige Komplexität beinhalten (wegen widersprüchlichenImplementationen und Nomenklaturen), was die Wartung unddie Flexibilität der Software bezüglich Erweiterungen erheblichreduziert.

Eine große Systemlandschaft hat oft zu viele Systeme und Teile,als dass man alles perfekt modellieren und implementierenkönnte. Es macht daher großen Sinn, sich ganz bewusst aufausgewählte Teile der Systemlandschaft zu konzentrieren unddort mehr zu investieren. Am besten konzentriert man sich auf

die so genannte Core Domain, auch Kernfachlichkeit genannt –jenen Aspekt, den die Firma und ihr Business einzigartig machtund den meisten Anwendernutzen stiftet. Meist hat eineSystemlandschaft Systeme und Funktionalitäten, die genauso gutin anderen Firmen auftreten können (z. B. ein DMS, Buchhaltungetc.), diese gehören nicht zur Core-Domain. Die Core-Domainherauszuschälen (Evans spricht von „destillieren“) kanndurchaus zu Überraschungen führen. Oft sind sich dieStakeholder nicht genau bewusst, was die Essenz ihres Businessgenau ausmacht oder zumindest ist man sich darüber nicht ganzeinig. In unserem Beispiel befragt der DDD-Berater nun nicht nurEntwickler, sondern auch Domänenexperten, dies sind Personen,die die Fachlichkeit und das Geschäft der Firma Amazine gutkennen, um die Core-Domain zu identifizieren. Wenn man sichAbbildung 1 anschaut, so könnte man schnell zum Schlusskommen, dass der Onlineshop die Core-Domain von Amazine ist.Dem ist jedoch nicht so. Es stellt sich heraus, dass dasEmpfehlungssystem Amazine von der Konkurrenz abhebt undsomit zur Kernkompetenz der Unternehmung geworden ist.Ohne das innovative Empfehlungssystem könnte sich dasUnternehmen kaum gegenüber sehr großenOnlinebuchhandlungen behaupten. Nach diesem Ergebniswurden umgehend mehr Entwicklerressourcen auf dieseswichtige System gesetzt.

Dem Unternehmensarchitekten hilft die Core-Domain-Methode,sich zu fokussieren und Schwerpunkte in der Systemlandschaftzu setzen, z. B. auch für Make-or-Buy-Entscheide: Eine Core-Domain-Funktionalität kann kaum oder nur sehr selten durchStandardsoftware abgedeckt werden, denn sie hebt sich perDefinition vom Standard ab und muss daher individuell erstelltwerden. Nimmt man trotzdem ein Standardprodukt, kann derStandardsoftwareanbieter dann die Versprechungen nicht halten,da man doch mehr „konfigurieren“ und „anpassen“ muss, alsursprünglich in der Offerte vorgesehen war. Abgesehen davonwürde das Unternehmen damit auch die heute notwendigeFlexibilität verlieren, wenn die Core-Domain nicht einfach undrasch anpassbar und veränderbar wäre. Das Unternehmenkönnte sich dann Veränderungen am Market nicht schnell genuganpassen.

Das Konzept der Core-Domain ist nicht nur für dieUnternehmensarchitektur sehr hilfreich. Auch demSystemarchitekten hilft es, den Fokus auf die wesentlichen undwichtigen Teile der Applikation zu lenken und Schwerpunkte inder Modellierung und Umsetzung zu setzen.

DDD auf Ebene SystemarchitekturWurden auf der Ebene Unternehmensarchitektur diewesentlichen Bereiche der Fachdomäne identifiziert, gilt es nun,die Umsetzung von einzelnen Systemen optimal zu gestalten.

Zuerst muss man sich als Architekt fragen, wie komplex dieGeschäftslogik ist, die das System umzusetzen hat. Für reineDatenerfassungsapplikationen, die bis auf simple Validierungenkaum Geschäftslogik umsetzen, lohnt es sich nicht, den initialenMehraufwand von DDD zu betreiben. Diese Art vonApplikationen werden oft auch CRUD-Applikationen genannt,wobei CRUD für Create Read Update Delete steht. DerEntwicklungsaufwand für CRUD-Applikationen bewegt sichtypischerweise im Rahmen von bis zu 3 Mann-Monaten. UmCRUD-Applikationen rasch und effizient umzusetzen, sind Rapid-Application-Development-Frameworks wie z. B. Spring Roo oderRuby on Rails eine gute Wahl. Falls die Geschäftslogik allerdingsrichtig Fleisch am Knochen hat, stellen diese Werkzeuge auflange Sicht nicht die optimale Lösung dar, da die Geschäftslogikzu eng an die einzelnen Masken resp. Datenbanktabellengekoppelt ist. Die Durchsetzung übergreifender Geschäftslogikwird zunehmend schwierig. In diesen Fällen lohnt es sich alsArchitekt, nach den Prinzipien von DDD eine saubereSystemarchitektur zu erarbeiten.

Als eine der Hauptaufgaben eines Architekten verstehen wir aufder Ebene Systemarchitektur die Definition von Modulen(Komponenten) eines Systems und deren Abhängigkeitenuntereinander. Voraussetzung dafür ist ein ausreichendesVerständnis der umzusetzenden Domäne, bevor die große Massean Entwicklern am Projekt mitarbeitet. Deshalb muss man aufder Ebene Systemarchitektur tiefer in die Details eintauchen alsnoch auf der Ebene Unternehmensarchitektur. Da nie alle Detailsberücksichtigt werden können, braucht man hier schlichtErfahrung, damit die kritischen Teile identifiziert und gezielt mit

den Domänenexperten vertieft werden können. Eine selbstgesetzte Deadline hilft, sich nicht in unwichtigen Details zuverlieren und sich immer wieder anhand der gewonnenenErkenntnisse auf die wichtigsten Punkte zu konzentrieren. Zieldieser initialen Modulbildung ist nicht ein perfektes Ergebnis,sondern eine relativ solide Grundlage. Später im Projekt darf mannicht davor zurückschrecken, die Modulbildung anzupassen.Eine „Wird nicht mehr angefasst“-Einstellung ist in der Regelkontraproduktiv, da für benötigte Änderungen einfach inanderen Modulen Workarounds erstellt werden. Dies ist eineForm von so genanntem Technical Debt, also eineQualitätsschuld, die ein System gegenüber der Zukunft aufweist.Diese Schuld rächt sich irgendwann in Form von verminderterRobustheit und Flexibilität des Systems, womit die Umsetzungvon Änderungen immer aufwendiger wird. Automatisierte Testsjeglicher Art (z. B. Unit Tests, Integrationstests etc.) helfen, dassdas System auch bei größeren Refactorings immer noch alsGanzes funktioniert. Solange man sich an die Konzepte von DDDzur Modulbildung hält, sind solche Anpassungen auch einfachmöglich.

Die wichtigste Grundregel zur Modulbildung bei DDD ist: DieAufgaben von Modulen und die Abhängigkeiten zwischenModulen müssen bewusst definiert und umgesetzt werden. DieModule dürfen dabei keine Abhängigkeitszyklen aufweisen,ansonsten können Änderungen an einem Modul rasch ziemlichviele andere Module betreffen. Abbildung 3 zeigt ein starkvereinfachtes Beispiel, wie eine solche Modularisierung für dasShopsystem aussehen könnte. Die Pfeile stellen „verwendete“Beziehungen dar, z. B. hat das Modul Bestellung eineAbhängigkeit auf das Modul Kunde. Daraus kann manschlussfolgern, dass Änderungen am Modul Kunde auch dasModul Bestellungen betreffen können, umgekehrt jedoch nicht.Die in der Abbildung 3 dargestellten Schichten sind Bestandteildes Layered-Architecture-Konzepts von DDD und sind in Tabelle1 erklärt.

Abb. 3: Modularisierung Shopsystem

Schicht Beschreibung

UI (UserInterface) Interaktion mit dem Benutzer (z. B. eine Web-GUI)

Application Koordiniert Aktionen, die auf der Domäne ausgeführt werden, enthält keineGeschäftslogik, kann z. B. Transaktionen öffnen/schließen und Fremdsysteme aufrufen

Domain Enthält das Domänenmodell, setzt geschäftsrelevante Daten und Geschäftsregeln um

Infrastructure Technische Infrastruktur, die von höheren Schichten verwendet werden kann, z. B. einPersistenzframework, Messaging-Infrastruktur usw

Tabelle 1: Layered Architecture nach DDD

Parallel zur Modulbildung verfeinert der Architekt dasDomänenmodell. Es ist das Herz der Abbildung der Fachlichkeitim System. Abbildung 4 zeigt ein wiederum vereinfachtesBeispiel, wie ein Domänenmodell für unser Shopsystem aussehenkönnte. Das Domänenmodell bildet die Ubiquituous Languagedes Shopsystems ab, ist aber oft zu abstrakt, um von

Domänenexperten verstanden zu werden. Das Domänenmodelldient primär als Kommunikationsmittel zwischen denEntwicklern und als Grundlage für das technisch umgesetzteModell. Da in der Geschäftswelt immer wieder ähnliche Muster inder Fachlichkeit auftauchen, sind Analyse-Patterns, wie z. B. vonFowler in [5] beschrieben, ein wichtiges Werkzeug bei derDefinition von Domänenmodellen. Die Bedeutung derverwendeten Stereotypen für Domänenklassen sind in [1]ausführlich erklärt. Aus Platzgründen verzichten wir hier aufeine Erklärung.

Abb. 4: Domänenmodell Shopsystem

Wie wir im ersten Abschnitt bereits erwähnt haben, liegen diegrößten Herausforderungen bei der Umsetzung eines nichttrivialen Systems oft nicht in der Technik. Zum Abschluss diesesAbschnitts möchten wir nun noch auf das Zusammenspielzwischen der Systemarchitektur und der Projektorganisationeingehen. Besonders wenn mehrere Entwicklungsteams andemselben System arbeiten, müssen Projektorganisation undSystemarchitektur aufeinander abgestimmt sein.

Die bereits definierten Module können nun einzelnenEntwicklungsteams zugewiesen werden. Ein Entwicklungsteamist jeweils für alle Aspekte seiner Module verantwortlich. Ganz imSinne von agilen Teams kümmert es sich interdisziplinär sowohlum das Erheben von Detailanforderungen wie auch um dieImplementation. Dies ermöglicht es Entwicklern, mitzudenkenund Lösungsvorschläge zu machen. Da die Module nachfachlichen Bereichen geschnitten sind, ist in der Regel auchbereits klar, welche Entwicklungsteams mit welchen

Domänenexperten kommunizieren müssen. Dies verhindert,dass die Domänenexperten von verschiedenen Teams zudemselben Thema befragt werden, und diese müssen somitweniger Zeit für das Projekt aufwenden.

Diese Vorgehensweise führt zu klaren Kommunikationswegenund Verantwortungen innerhalb eines Projekts, was denKoordinationsaufwand senkt und somit die Effizienz allerBeteiligten deutlich steigert.

DDD auf Ebene ImplementationIn klassischen Systemarchitekturen von Enterprise-Applikationenbefindet sich meist die gesamte Geschäftslogik in Serviceklassen,während die Domänenklassen reine Daten-Container darstellen.In einem DDD-System enthalten Domänenklassen neben ihrenDaten jedoch auch die dazugehörige Geschäftslogik. Dadurchkönnen Domänenobjekte ihre Geschäftsregeln selbst durchsetzenund ein Domänenobjekt bleibt in sich konsistent. WeitereAspekte bei der Implementation können unter anderem in [6]nachgelesen werden.

Da zumindest im Java-Umfeld die meisten Frameworks undBibliotheken nicht auf Domain-Model-Architekturen ausgelegtsind, muss man den einen oder anderen technischen Stolpersteinaus dem Weg räumen. Damit wir diese nicht immer wieder vonneuem wegräumen müssen, haben wir uns mit mimacom patheine schlanke Sammlung an Guidelines und bereits existierendenFrameworks und Bibliotheken (wie z. B. Spring)zusammengestellt. Wo die eingesetzten Frameworks noch nichtganz ausreichen, haben wir das Paket durch eigenen Gluecodeergänzt.

FazitIn diesem Artikel sind aus Platzgründen nur einige ausgewählteKonzepte und Methoden von Domain-driven Design verwendetworden. Beim ersten Kontakt mit DDD empfinden viele Leser dieMethoden als „esoterisch“ oder als „zu simpel“. Bei derAnwendung merkt man jedoch rasch, dass sie sehr pragmatischund effektiv sind und das Lernen von Domänenwissen fördern.Das Lernen ist ein wichtiger Bestandteil des DDD-Denkens, dennman schafft es kaum, beim ersten Kontakt mit der Domäne ein

perfektes Modell zu definieren. Durch kontinuierlichenAustausch mit Domänenexperten kann das Modell iterativverbessert werden. Dadurch wird die Software auch robuster undflexibler. Zudem wird das Hauptziel erreicht, nämlich den Nutzenfür den Endbenutzer zu erhöhen. Zu diesem Prozess gehört esauch, dass die Architekten selbst am Keyboard sitzen und dieModelle implementieren, denn zu den Benutzern der Softwaregehören auch die Entwickler in der Entwicklung und derWartung.

Es gibt sehr viel Wissen, Bücher und Quellen, wie man robusteund flexible Software bauen kann. Alle Methoden nutzen jedochherzlich wenig, wenn die Entwickler und Architekten nicht stetigdie Disziplin aufbringen, dieses Wissen anzuwenden, Tests zuschreiben, das Modell zu verbessern, an der Kommunikation mitKollegen zu feilen und die Haltung pflegen, qualitativhochwertige Arbeit abzuliefern. Und dies auf allen drei Ebenen.

Martin Kernland arbeitet als Senior Software Architectbei der edorasware ag, einer innovativen Firma imBereich BPM und Enterprise Work Management. In derFreizeitunterstützt er die Java-Community als Präsidentder Java User Group Switzerland (jug.ch).

Adrian Gygaxm arbeitet als Senior Software Engineerund IT-Architekt bei der mimacom ag.DDD konnte er inder Praxis bereits in mehreren Projekten auf allenArchitekturebenen anwenden.

Links & Literatur[1] Evans, E.: „Domain-Driven design: tackling complexity in theheart of the software “, Addison-Wesley, 2004

[2] http://www.opengroup.org/togaf/

[3] http://de.wikipedia.org/wiki/Zachman_Framework

[4] http://de.wikipedia.org/wiki/Mars_Climate_Orbiter

[5] Fowler, M.: „Analysis Patterns: Reusable Object Models“,Addison-Wesley, 1996

[6] Vernon, V.: „Implementing Domain-Driven Design“, Addison-Wesley, 2013

Interview mit Jimmy Nilsson

„Man braucht einen Tag, um vonDDD zu profitieren, aber einganzes Leben, um es zu meistern“In Rahmen unseres Themen-Dossiers zu Domain-driven Designhaben wir mit Jimmy Nilsson gesprochen, der der DDD-Bewegung mit seinem Buch „Applying Domain-Driven Designand Patterns“ wichtige Impulse verliehen hat. Was war und istan DDD so inspirierend? Wie stehen DDD und Microserviceszueinander? Welche aktuellen Architektur-Trends sollten wirim Auge behalten?

Inspirationsquelle Domain-driven DesignJAXenter: Hallo Jimmy. Vielen Dank, dass du dir die Zeit fürdieses Interview genommen hast!Jimmy Nilsson: Vielen Dank für die Einladung!

JAXenter: Das Konzept des Domain-driven Design wurdeAnfang 2000 geprägt. Du selbst hast mit deinem Buch“Applying Domain-driven Design and patterns” einenwichtigen Beitrag geleistet. Wenn du dich ein wenig in dieseAnfangszeit zurückversetzt: Welche Probleme hatte dieSoftware-Entwicklung vor Domain-driven Design, die dann vonder DDD-Bewegung angegangen wurden?Jimmy Nilsson: Ich denke, damals bestand der erste wichtigeBeitrag von DDD darin, eine Reihe nützlicher Werkzeuge bereitzu stellen, um die schwierige Aufgabe zu lösen, wirklich gute,aussagekräftige Domänenmodelle zu erstellen. Genauso wie vieleandere habe auch ich jahrelang mit diesem Thema gerungen, undDDD wurde da als eine riesige Inspirationsquelle empfunden.

DDD war für uns eine riesige Inspirationsquelle.

Aber was noch wichtiger, ja sogar viel wichtiger war, waren diephilosopischen Aspekte von DDD. Beispielsweise der Fokus auf

d i e Zusammenarbeit zwischen praktizierenden Software-Entwicklern und Domänenexperten und das ständige Bestrebenim Arbeitsalltag, ein gemeinsames Verständnis eines Problemsund der gewählten Lösung zu finden. Das ist auch heute noch derPunkt, den ich in den verschiedenen Projekten, in die ich mehroder weniger tief involviert bin, am häufigsten betone.

JAXenter: Was hat dich persönlich so an DDD gereizt?Jimmy Nilsson: Nun, da gibt es so viele Dinge. Ich denke,Domain-driven Design und Test-driven Development (TDD)waren für mich die beiden wichtigsten Inspirationen, um einbesserer Entwickler zu werden. Doch wenn ich spontan eineSache herausgreifen soll… Ich denke, DDD ist deshalb soanziehend, weil es ein typisches Beispiel für das Sprichwort ist:„Man braucht ein oder zwei Tage, um davon zu profitieren, aberein ganzes Leben, um es zu meistern.“

Ich gehe davon aus, dass ich von Domain-driven Design noch inmeiner gesamten Karriere profitieren werde. DDD ist genau dasGegenteil von “und wieder ein neues Framework”, von Dingenalso, die plötzlich auf der Bildfläche erscheinen, um nach einemoder zwei Jahren genauso schnell wieder zu verschwinden.

Domain-driven Design in der PraxisJAXenter: Häufig sind den Entwicklern die Prinzipien von DDDgrundsätzlich bekannt. Nur ist die Umsetzung alles andere alstrivial. Was sind deiner Erfahrung nach die typischen Problemebei der Anwendung von DDD in echten Projekten?Jimmy Nilsson: Ein typisches Problem ist, dass DDD in realenProjekten nur als ein Technologie-Stil genutzt wird. So hilft esnicht wirklich viel, ist zugleich für die Entwickler aberanspruchsvoll in der Umsetzung. Das Ergebnis ist eine niedrigeProduktivität, ohne wirklich von den Vorteilen zu profitieren.

Wir sollten uns mehr auf den Aspekt der Zusammenarbeitkonzentrieren.

JAXenter: Hast du einen Tipp für unsere Leser, wie man diesesProblem lösen kann?Jimmy Nilsson: Ich schlage vor, sich auf den Aspekt der

Zusammenarbeit zu konzentrieren, anstatt verschiedene Modellezur Problemlösung zu untersuchen. Spiele mit diesen Modellen,probiere sie aus. Und stelle dich darauf ein, dass sie sich ändernwerden. Höre nie auf, die Modelle während der Anwendung zuverbessern.

JAXenter: Mit deinem Buch „Applying Domain-driven Designand patterns“ hast du eine Brücke geschlagen zwischen EricEvans’ DDD-Konzept und Martin Fowlers „Patterns ofEnterprise Architecture“. Denkst du, die Kluft zwischembeidem existiert heute immer noch?Jimmy Nilsson: Auf jeden Fall. Ich sehe zwar viele Projekte, indenen die Kluft schmaler geworden ist. Aber meistens klafft danoch eine große Lücke auf.

DDD und MicroservicesJAXenter: Wenn wir uns die heutigen Diskussionen umSoftware-Architektur ansehen, dann ist DDD immer noch sehrrelevant. Im Kontext der Microservice-Debatte erleben wirvielleicht sogar so etwas wie ein Revival der DDD-Prinzipien.Was denkst du über Microservices?Jimmy Nilsson: In vielen Situationen beziehe ich mich gerne aufdas, was ich den „Bounded-Context-Stil“ von Microservicesnenne. Ich habe 2009 einen Artikel geschrieben, der immer nochbeschreibt, wie ich Microservices grundsätzlich sehe (obwohl derTeil über Datenspeicherung veraltet ist). Aber „Microservices“ istdefinitiv der bessere Namen dafür.

JAXenter: Welcher Aspekt von DDD wird in der heutigen Praxisam meisten vernachlässigt?Jimmy Nilsson: Nun, auf die Gefahr hin, dass ich michwiederhole: Ich denke, dass tatsächlich die Idee des Miteinandersund des gemeinsamen Verständnisses einer Sache die Antwortauf diese Frage ist. Ein anderer Aspekt, der mit Microserviceszusammenhängt, ist das „strategische Design“ von DDD. Dieserstrategische Aspekt ist beispielsweise extrem nützlich, wenn manein schwieriges, groß angelegtes und undurchsichtiges Projektübernimmt, da er hilft, Ordnung zu schaffen.

JAXenter: Wo liegen momentan deine Interessen im Bereich

Software-Architektur/Methodologie?Jimmy Nilsson: Aktuell interessiert mich hauptsächlich,Unternehmens-spezifische Sprachen zu entwickeln, die bei derZusammenarbeit zwischen Domänen-Experten und Software-Entwickler helfen. Diese Sprachen ersetzen normalen C#/Java-Code, der eher ein Hindernis für die Zusammenarbeit darstellt, daes immer eine Art Übersetzungslücke zwischen Technikern undDomänen-Experten gibt. Die Beschreibungen in derUnternehmens-spezifischen Sprache werden dann mit Firmen-spezifischen Engines ausgeführt, die die benötigte Architektur zurVerfügung stellen. Ich finde das enorm spannend, besonders weildie möglichen positiven Effekte so groß sind.

JAXenter: Vielen Dank für dieses Interview!

Jimmy Nilssonist CEO und Gründer des Unternehmensfactor10 und seit über 25 Jahren als Entwickler undSystem-Architekt tätig. Als Autor des Buches “ApplyingDomain-Driven Design and Patterns” hat er der DDD-Bewegung wichtige Impulse verliehen. Jimmy ist Sprecher

auf zahlreichen internationalen Konferenzen, darunter OOPSLA,GOTO, JAOO, NDC, Oredev und TechEd.

Domain-driven Design und Microservices

Reactive Microservices mit Scalaund AkkaVaughn Vernon zeigt in diesem Artikel einen Zugangsweg zumThema Microservices auf, der die Grundlage für die weitereBeschäftigung mit dem Thema bilden kann. Er stellt dazu dasreaktive Programmiermodell vor und erklärt, wie Domain-driven Design für die Entwicklung reaktiver Microserviceseingesetzt werden kann.von Vaughn Vernon

Hatten Sie jemals den Eindruck, dass unsere Branche vonExtremen geprägt ist? Ich habe manchmal dieses Gefühl. VieleEntwickler scheinen eine sehr polarisierte Meinung zu vertreten,egal, ob es nun um die Entwicklung von Software oder derenFunktionsweise geht. Ich glaube indes, dass wir ein Gleichgewichtzwischen diesen Positionen erreichen könnten, wenn wir uns aufdas Problem konzentrieren, das gerade anliegt.

Dabei denke ich zum Beispiel an die weit verbreitete Meinung,dass Daten per ACID-Transaktionen persistiert werden müssen.Ich möchte nun nicht falsch verstanden werden: Es ist nicht so,dass ich ACID-Transaktionen nicht nützlich finde. Das sind sie –

sie werden allerdings viel zu oft benutzt. Könnten wir hier alsonicht ein besseres Gleichgewicht finden?

Nehmen wir einmal an, dass über verschiedene Teilsystemeverteilte Daten eine gewisse Übereinstimmung aufweisenmüssen. Manche bestehen nun darauf, dass solche abhängigenDaten auf der Transaktionsebene konsistent sein sollten, alsoüberall zur gleichen Zeit auf dem gleichen Stand sein müssen(Abbildung 1).

Abbildung 1: Globale Transaktion

Würden Sie dieser Sichtweise zustimmen? Verwenden einigeIhrer Software-Systeme solche globalen Transaktionen, um Datenin multiplen Systemen zu synchronisieren? Wenn ja, warum?Haben die Business-Stakeholder darauf bestanden, das so zumachen? Oder haben Sie an der Uni gelernt, warum dieKonsistenz globaler Transaktionen wichtig ist? War es derDatenbank-Anbieter, der Ihnen ein derartiges Service-Level-Agreement verkauft hat?

Die wichtigste dieser drei Positionen ist die Business-Perspektive.Echte geschäftskritische Aspekte sollten darüber bestimmen,wann Daten konsistent sein müssen. Wann aber haben Sie zuletztauf geschäftlicher Ebene nach den Anforderungen an die Daten-Konsistenz gefragt; was hat das Business-Ebene dazu gesagt?

Wenn wir einmal in die Prä-Computer-Ära zurückblicken, als diemeisten Geschäftsfelder noch nicht von IT-Aspekten bestimmtwaren, sehen wir ein deutlich anderes Bild der Datenkonsistenz.Damals war so gut wie gar nichts konsistent. Es konnte Stundenoder sogar Tage dauern, bis geschäftliche Transaktionenvollständig ausgeführt waren. Mit Papier-basierten Systemen istes notwendig, Daten physisch vom Tisch eines Mitarbeiters zumnächsten zu tragen. Damals war selbst eine halbwegs vernünftigeDatenkonsistenz absolut unerreichbar. Der springende Punktdabei: Zu Problemen hat dies nicht geführt!

Mal im Ernst: Wenn man heute eine ehrliche Antwort auf dasnotwendige Maß der Datenkonsistenz auf Geschäftsebenebekäme, müsste diese häufig wohl lauten, dass viele Daten nichtbis auf die Millisekunde konsistent sein müssen. Trotzdembringen extreme Sichtweisen in unserer Branche viele Entwicklerdazu, überall eine absolute Datenkonsistenz anzustreben(Abbildung 2).

Abbildung 2: Isolierte Transaktion

Wer mit Microservices arbeiten möchte, muss sich mit einerEventual Consistency anfreunden, einer Konsistenz also, dielediglich garantiert, dass ein Datensatz nach einer gewissenZeitspanne konsistent sein wird. Er muss verstehen, dass das demGeschäft meistens nicht im Weg steht, selbst wenn Uni-Professorund Datenbank-Anbieter etwas anderes sagen. Ich erkläre späterin diesem Artikel, wie das funktioniert.

Microservices & Domain-driven DesignEs gibt noch ein weiteres Extrem, das sich in letzter Zeiteingeschlichen hat. Es geht um die Servicegröße, vor allem inHinblick auf die Verwendung von „Microservices”. Was ist ein

Microservice überhaupt, und was bedeutet das „Micro” für seineGröße? Es werden da zum Teil verschiedene Richtlinienausgegeben: Einige sprechen von 100, 400 oder 1000 Zeilen Code.

Wirklich? Ja, ich habe tatsächlich gesehen und gehört, dassMicroservices nicht mehr als 100 Zeilen Code umfassen sollten.Andere sprechen von 400 Zeilen Code, manche sind etwasgroßzügiger und erlauben 1000 Zeilen. Also, was stimmt dennnun?

Ich glaube nicht, dass irgendeines dieser Extreme als Richtliniefür die Größe eines Microservices dienen kann. Wenn manbeispielsweise der Regel zustimmt, dass Microservices nicht mehrals 400 Zeilen Code haben sollten – bedeutet das, dass meinMicroservice mit 537 Zeilen Code zu groß ist? Gibt es einemagische Grenze bei 400 Zeilen Code, die dafür sorgt, dass derService dann genau richtig ist?

Auf der anderen Seite gibt es aber auch diejenigen, die das andereExtrem vertreten und daran glauben, dass Softwaresysteme alsMonolithen entwickelt werden sollten. In diesem Fall muss mandavon ausgehen, dass so gut wie jedes Teilsystem, das zurUnterstützung des Kernsystems notwendig ist, in einer einzigenCodebasis zu finden ist. Wird dieses System nun deployt, müssenalle Teilsysteme mit deployt werden. Wenn sich nur eineKleinigkeit in einem Teilsystem ändert, selbst wenn das dieanderen Teile nicht beeinflusst, muss das gesamte System neudeployt werden, damit diese eine, isolierte Änderung beim Nutzerankommt.

Natürlich scheint dieser Ansatz klare Nachteile zu haben; dochsind 400 Zeilen Code die Lösung (Abbildung 3)?

Abbildung 3: Monolith vs. Microservices

Ich denke, dass die Betonung beim Wort „Micro” mehr daraufliegen sollte, dass das Team keinen Monolithen baut, sondernstattdessen kleinere, unabhängige Services entwickelt, diezusammenarbeiten, um wichtige Geschäftsziele zu erreichen. Zusagen, dass ein Service, der zu den „Micro”-Services gehört, nichtmehr als 400 Zeilen Code haben darf, ist keine ausgeglichenePosition.

Nehmen wir einmal an, dass wir ein bereits bestehendesmonolithisches System in Komponenten von jeweils nicht mehrals 400 Zeilen segmentieren wollen, um diese dann zu deployen.Bei 400 Zeilen Code sprechen wir dann wahrscheinlich davon,dass jeder Microservice nur einen Entity-Typ umfassen soll. Dannhätte man am Ende hunderte bis tausende von sehr kleinenMicroservice-Komponenten. Welchen Problemen könnte sich einTeam nun also gegenübersehen, wenn es um die Administrationall dieser Microservices geht? Allein schon die Hardware und dieNetzwerk-Infrastruktur wären sehr komplex. Es könnte gelindegesagt ziemlich schwierig werden, ein solches System zu erstellenund zu pflegen.

Wenn wir nun aber nach einem Gleichgewicht in Sachen „Micro”suchen, könnte sich ein „Maßstab” für die Service-Größeanbieten, der nicht nur logisch, sondern sogar aufGeschäftsprozesse ausgerichtet ist. Da ich ein großer Befürworterdes Domain-Driven Design (DDD) in der Softwareentwicklungbin, schlage ich dazu die Anwendung der zwei wichtigstenKonzepte des DDD vor, um die Größe von Microservices zubestimmen: Bounded Context und Ubiquitous Language(Abbildung 4).

Abbildung 4: Bounded Context

Wer das Buch „Building Microservices” von Sam Newmanngelesen hat, weiß bereits, dass Sam sagt, dass Microservices vomBounded Context definiert werden sollten. Sam und ich stimmendarin überein. Die Aussage, dass ein Microservice ein BoundedContext ist, umfasst allerdings noch keine Information zur Größedes Microservice. Das liegt daran, dass die Größe des BoundedContext von seiner Ubiquitous Language bestimmt wird. Wennman also die Größe des Bounded Context (und somit desMicroservice) wissen möchte, muss man die Ubiquitous Languagefragen.

Die Ubiquitous Language des Bounded Context wiederum wirdgemeinsam von Experten für die Branche und Entwicklernbestimmt. Man muss verstehen, dass die Verwendung derSprache der Business-Treiber bedeutet, dass alle linguistischzusammenhängenden Komponenten im selben Bounded Contexterscheinen. Was linguistisch nicht zu einem bestimmtenBounded Context gehört, gehört somit zu einem anderen

(Abbildung 5).

Abbildung 5: Verschiedene Bounded Contexts

Ich habe festgestellt, dass ein Bounded Context, der wirklich voneiner Business-getriebenen Ubiquitous Language begrenzt wird,recht klein ist. Er ist typischerweise größer als eine Entity(obwohl auch ein so kleiner Bounded Context möglich ist), abergleichzeitig viel, viel kleiner als ein Monolith. Es ist unmöglich,eine exakte Zahl anzugeben, weil die Ubiquitous Languagekomplett vom jeweiligen Geschäftsbereich bestimmt wird. VieleBounded Contexts umfassen aber, um dennoch einmal eine Zahlin den Raum zu werfen, insgesamt zwischen 5 und 10 Entity-Typen. 20 Entity-Typen könnten hingegen schon einen großenBounded Context darstellen.

Insofern ist ein Bounded Context also von einem kleinen, ja, voneinem „Micro”-Format, vor allem wenn man ihn mit einemMonolithen vergleicht. Wenn man jetzt darüber nachdenkt,einen Monolithen in eine Reihe von Bounded Contexts zuunterteilen, wird die Depolyment-Topologie nicht ganz sounübersichtlich.

Ich glaube, dass das ein guter Ausgangspunkt ist, wenn ein Team

sich vornimmt, einen Legacy-Monolithen in eine Reihe vonMicroservices zu unterteilen. Wer mit Bounded Context undUbiquitous Languages seine ersten Schritte in die Welt derMicroservices tut, wird die Monolithen schnell hinter sich lassen.

Was ist Reaktive Software?Reactive Software wird anhand dieser vier zentralen Merkmaledefiniert:

ResponsivResilientElastischMessage Driven

Responsiv ist ein System, wenn es auf herausragende Weise aufUser Requests und Integrationen im Hintergrund reagiert. Werdie Lightbend Platform verwendet, wird beeindruckt davon sein,wie viel Responsiveness sich erreichen lässt. Ein gut designterMicroservice kann Write-basierte Requests in 20 Millisekundenoder weniger verarbeiten, sogar die Hälfte dieser Zeit ist nichtselten.

Systeme, die unter Verwendung von Akka auf dem Aktoren-Model basieren, können unglaublich resilient sein. Supervisor-Hierarchien sorgen dafür, dass die Eltern-Kette vonKomponenten für das Auffinden und Beheben von Fehlernzuständig ist, sodass die Clients nur noch mit den Servicesbeschäftigt sind, die sie benötigen. Anders als bei Code, der inJava geschrieben ist und Exceptions auswirft, müssen sich Clientsvon Aktor-basierten Services nie selbst mit Fehlern des Aktorenbefassen, von dem sie einen Service anfordern. Clients müssenstattdessen nur den Request-Response-Contract verstehen, densie mit einem bestimmten Service eingehen, und Requestsgegebenenfalls wiederholen, wenn keine Antwort in einembestimmten Zeitraum erfolgt.

Elastisch ist eine Microservice-Plattform dann, wenn sie je nachBedarf hoch und herunter skalierbar ist. Ein Beispiel dafür ist einAkka Cluster, das ohne Funktionsverlust auf 2400 Nodesskalieren kann. Elastisch bedeutet aber auch, dass nur so vieleNodes zugewiesen werden, wie gerade notwendig sind – also

keine 2400 Nodes, wenn sie nicht gebraucht werden. Wenn manAkka und andere Komponenten der Reactive Platform ausführt,gewöhnt man sich daran, deutlich weniger Server zu verwendenals mit anderen Plattformen (z.B. JEE). Das liegt daran, dass AkkaFähigkeiten im Bereich der Nebenläufigkeit mitbringt, die esMicroservices erlauben, die Ressourcen aller Server jederzeit zunutzen, ohne sie dafür zu blockieren.

Das Aktoren-Modell in Akka ist bis in den Kern Ereignis-getrieben. Um einen Service von einem Aktoren abzurufen, wirdeine Nachricht abgeschickt, die asynchron ausgeliefert wird. Umauf einen Request von einem Client zu antworten, schickt derService-Aktor eine Nachricht an den Client, die ebenfallsasynchron ausgeliefert wird. Mit der Reactive Platform arbeitenauch Web Components asynchron. Der Persistenz-Mechanismusist grundsätzlich als asynchrone Komponente angelegt, wenn ereinen Persistent State eines Aktoren speichert. Das bedeutet, dassInteraktionen mit der Datenbank entweder komplett asynchronoder nur minimal blockierend ablaufen. Der zentrale Punkt isttatsächlich, dass der Aktor, der die Persistenz angefragt hat, denThread nicht blockiert, solange er darauf wartet, dass dieDatenbank die Anfrage bearbeitet. Das alles ist aufgrund desasynchronen Messagings möglich.

Reaktive KomponentenAuf jeder logischen Schicht der Architektur finden sich diefolgenden Lightbend Plattform- und Microservice-Komponenten,die Ihr Team verwenden oder weiterentwickeln kann (Abbildung6).

Abbildung 6: Lightbend Platform Components

Wie ein Persistenz-Aktor auf Basis von Akka aussieht, zeigtListing 1.

class Product(productId: String) extends PersistentActor {

override def persistenceId = productId

var state: Option[ProductState] = None

override def receiveCommand: Receive = {

case command: CreateProduct =>

val event = ProductCreated(productId, command.name,

command.description)

persist(event) { persistedEvent =>

updateWith(persistedEvent)

sender ! CreateProductResult(

}

... }

productId,

command.name,

command.description,

command.requestDiscussion)

override def receiveRecover: Receive = {

case event: ProductCreated => updateWith(event) ...

}

def updateWith(event: ProductCreated) {

state = Some(ProductState(event.name, event.description,

false, None))

} }

Listing 1

Diese Komponente basiert auf Event Sourcing. Die Product Entity

erhält Commands und gibt Events aus. Die Events werdenverwendet, um den Status der Entity festzulegen, sowohlwährend die Commands verarbeitet werden als auch wenn dieEntity angehalten, aus dem Speicher entfernt und dann aus altenEvents wiederhergestellt wird.

Aus diesen Events können wir nun weiteren Nutzen ziehen.Zuerst können wir Events in Views projizieren, die die Nutzer zusehen bekommen, indem wir auf bestimmte Anwendungsfällezugeschnittene Queries erstellen. Zweitens können die Eventseiner größeren Anzahl von Microservices zugänglich gemachtwerden, die darauf reagieren und mit dem Microserviceinteragieren müssen, der das Event ausgegeben hat (Abbildung7).

Abbildung 7: Event-driven Architecture

Was ich hier beschreibe, ist eine Ereignis-getriebene Architektur,die komplett reaktiv ist. Aktoren innerhalb aller Microservicesmachen sie reaktiv; Microservices, die Events aus anderenMicroservices konsumieren, sind ebenfalls reaktiv. An dieserStelle kommt die Eventual Consistency in verschiedenenTransaktionen ins Spiel. Wenn andere Microservices die Eventssehen, erzeugen und/oder modifizieren sie den Zustand, den siein ihrem Kontext besitzen, und sorgen so nach und nach für dieÜbereinstimmung des gesamten Systems.

Vaughn is a veteran software craftsman, with more than30 years of experience in software design, development,and architecture. He is a thought leader in simplifyingsoftware design and implementation using innovativemethods. Vaughn is the author of the books

„Implementing Domain-Driven Design”, „Reactive MessagingPatterns with the Actor Model”, and „Domain-Driven DesignDistilled”, all published by Addison-Wesley. Vaughn speaks andpresents at conferences internationally, he consults, and has taughthis „IDDD” Workshop and „Go Reactive with Akka” workshoparound the globe to hundreds of developers. He is also the founderof „For Comprehension”, a training and consulting company, foundat ForComprehension.com You may follow him on Twitter:@VaughnVernon

Interview mit Stefan Tilkov

„Ich bin keinesfalls der Meinung,dass man immer Microserviceseinsetzen sollte“Microservices oder Software-Monolithen – über dieseArchitekturfrage wird momentan teils kontrovers diskutiert.Wir haben Stefan Tilkov, Principal Consultant bei innoQ, umeinen Beitrag zur Debatte gebeten. Dabei kommt auch dasProblem in den Blick, wie Legacy-Anwendungen an moderneArchitektur-Ansätze herangeführt werden können.JAXenter: Wir wollen uns ein wenig über aktuelle Themen derSoftware-Architektur unterhalten. Momentan kommt dasKonzept des Domain-driven Design wieder in Mode – einKonzept, das ja schon 2003 geprägt wurde. Weshalb wird heutewieder verstärkt über DDD gesprochen?Stefan Tilkov: Unsere Systeme werden immer mächtiger undgrößer – und als Konsequenz leider auch immer komplexer. Diedaraus entstehenden Probleme, die ganz besonders bei einergroßen, monolithischen Code-Basis entstehen, plagen im Momenteine Vielzahl unterschiedlicher Organisationen undUnternehmen. Genau dabei helfen die strategischen Bestandteilevon DDD, also Bounded Context & Co., weil sie große Modellehandhabbar machen und ein Rezept für erfolgreicheModularisierung liefern.

DDD liefert ein Rezept für erfolgreiche Modularisierung.

JAXenter: Nun ist die Umsetzung von DDD in die Praxis nichteinfach. Wo liegt deiner Erfahrung nach dieHauptschwierigkeit – und wie kann man diese überwinden?Stefan Tilkov: Wie immer ist das eine Mischung ausunzureichender Ausbildung und dem verständlichen Festhaltenam vermeintlich Notwendigen. So können sich viele Architektenund Entwickler nicht vorstellen, wie die unweigerlich bei DDD

entstehende Redundanz eine gute Sache sein soll. Wenn man sichaber ein konkretes Modell vornimmt, stellt man man rechtschnell fest, dass die ach so zentralen Strukturen nur ausBequemlichkeit zentral sind und sich häufig sehr gut inweitgehend disjunkte Bestandteile zerlegen lassen. Hat man dasein paar Mal gemacht, fragt man sich, wieso man nicht vonvornherein so vorgegangen ist. In Kurzform: Man muss eseinfach einmal „durchziehen“, die Erfahrung hat oft großeKonsequenzen.

JAXenter: Im Rahmen der Microservice-Debatte hast du voreinigen Monaten die u.a. von Martin Fowler vertretene Ideezurückgewiesen, man solle zunächst einen Software-Monolithen bauen und diesen dann in Microservices aufteilen.“Don’t start with a monolith – … when your goal is amicroservices architecture”, hieß dein Beitrag. Was ist für dichausschlaggebend gewesen, dazu zu raten, gleich mitMicroservices zu beginnen?Stefan Tilkov: Um es vorab noch einmal klar zu sagen: Ich binkeinesfalls der Meinung, dass man immer Microserviceseinsetzen sollte und Monolithen immer schlecht sind. Ich findeMonolithen prima und bin deswegen der Meinung, dass wir ganzviele davon bauen sollten … Aber zu der konkreten Aussage:Wenn es so leicht wäre, ein monolithisches System so modular zuentwickeln, dass man es im Nachhinein in Microservicesaufteilen kann – bräuchten wir die Aufteilung nicht mehr! Ofthelfen die klaren Grenzen zwischen einzelnen Systemen oderServices, die sich nicht bzw. nur mit Aufwand überwinden lassen:Sie stellen sicher, dass die nun stärker getrennten einzelnenModule ihre eigenen lokalen Optima wählen können und stärkerisoliert sind.

JAXenter: Nun sieht die Realität in Unternehmen meist so aus,dass bereits eine Anwendungslandschaft vorliegt – und meistbesteht diese aus Software-Monolithen. Wir kommen damit zudeinem Thema auf dem Software Architecture Summit,nämlich dem Thema der Architektur-Transformation. Wieschafft man es (technologisch), eine Legacy-Anwendung anmoderne Architektur-Ansätze wie Microsrvices, PaaS, Cloud,Continuous Delivery heranzuführen?

Stefan Tilkov: Zunächst einmal muss man sich der Tatsachestellen, dass man nicht alle Schlachten gleichzeitig kämpfen undgewinnen kann, sondern die wichtigsten Dinge in denMittelpunkt stellen. Für eine Legacy-Anwendung führt der Wegin die Zukunft aus meiner Sicht über die Umsetzung von neuenfachlichen Anforderungen in eine neue Architektur. Dazu gibt eseine Reihe von Mustern, die sich in der Praxis bewährt haben.Mindestens genauso wichtig ist aber auch der organisatorischeAspekt – wenn man die Teams nicht abholt und die Organisationden Plan sabotiert, wird auch die tollste Technologie scheitern.Das Ganze muss deshalb aus einem (schlanken) strategischen Teilbestehen, der mithilfe kurzfristig nützlicher taktischerMaßnahmen umgesetzt wird. Der genaue Weg ist in jedemKontext ein anderer.

Man kann nicht alle Schlachten gleichzeitig kämpfen.

JAXenter: Bei solchen Transformationen spielen ja auch Politikund Betriebswirtschaft eine wichtige Rolle spielen, oder?Stefan Tilkov: Politik spielt – gerade in großen Unternehmen –natürlich immer eine wichtige Rolle. Nur indem man diewichtigen Personen auf allen Ebenen “mitnimmt”, kann manletztlich erfolgreich sein. Betriebswirtschaft ist wichtig, weilArchitekturumbaumaßnahmen Geld kosten, der Nutzen aber fürdie Geldgeber oft in keiner Weise transparent ist. Die meistenArchitekturtransformationen müssen daher mit einem fachlichenThema kombiniert werden – die Businessseite bekommt einneues Feature mit fachlichem Nutzen und dieArchitekturverbesserung kommt nebenbei mit.

JAXenter: Vielen Dank für dieses Interview!

Stefan Tilkov ist Geschäftsführer und PrincipalConsultant bei der innoQ Deutschland GmbH, wo er sichvorwiegend mit der strategischen Beratung von Kundenim Umfeld von Softwarearchitekturen beschäftigt. Er istAutor des Buchs „REST und HTTP“, Mitherausgeber von

„SOA-Expertenwissen“ (beide dpunkt.verlag), Autor zahlreicherFachartikel und häufiger Sprecher auf internationalen Konferenzen.

Die Renaissance von Domain-driven Design

Microservices lieben Domain-driven DesignDas Buch „Domain-Driven Design“, das Eric Evans vor gutdreizehn Jahren publizierte, gilt schon seit jeher alsherausragende Referenz für die fachlich getriebeneModellierung von IT-Systemen. Mit dem Einzug vonMicroservices erfährt Domain-driven Design eine Renaissance,denn die beiden Ideen lassen sich wunderbar miteinanderkombinieren.von Michael Plöd

Betrachtet man diverse Publikationen rund um Domain-drivenDesign und Microservices, so stellt man fest, dass das Konzept desBounded Contexts von zentraler Natur ist. Es gibt kaum eineVeröffentlichung zur Modellierung von Microservices, die diesesKonzept nicht erwähnt. Allerdings greift diese Konstellation zukurz: Es gibt weitaus mehr über Domain-driven Design undMicroservices zu berichten als den Bounded Context. Betrachtetman auf der anderen Seite das Thema Domain-driven Design, soist festzustellen, dass das Thema weit über die hinlänglichbekannten Entitäten, Value Objects und Aggregate hinausgeht.

Im Kontext von Microservices hilft uns Domain-driven Design invier Bereichen: Das strategische Design hilft bei derStrukturierung von Microservices-Landschaften und demBeschreiben von Liefer- und Leistungsbeziehungen zwischeneinzelnen Microservices. Der Bereich der internen Bausteine hältLösungsvorschläge für den internen Entwurf einzelnerMicroservices bereit. Die Ideen und Patterns des Domain-driven-Design-Kapitels zum Thema große Strukturen helfen uns bei derEvolution von schnell wachsenden Microservices-Landschaften.Abschließend liefert der Bereich der Destillation Anregungen undIdeen für das Refactoring bestehender Anwendungen in Richtungvon Microservices.

Strategisches Design mit Bounded ContextZentrale Idee des strategischen Designs (Strategic Design) ist derBounded Context. Dieser ist eine gute Hilfestellung für das Findeneiner passenden Granularität für Microservices. Jedeanspruchsvollere Fachdomäne wird mit Sicherheit aus mehrerenBounded Contexts bestehen. Ein Bounded Context ist rein formellals Gültigkeitsgrenze für ein fachliches Modell zu betrachten.Diese auf den ersten Blick abstrakt wirkende Definition ist jedochrecht leicht zu verstehen, wenn man sie anhand eines konkretenBeispiels betrachtet. Angenommen, wir wollen eine neueAnwendungslandschaft für die Organisation einer Konferenz wieder W-JAX entwickeln. Eine solche Fachlichkeit hat vereinfachtbetrachtet beispielsweise drei Domänen:

die Registrierung von Anmeldungenden Druck der Konferenzpässe für die Besuchereine Kapazitätsplanung für Essen und Sessions

Diese Domänen lassen sich als einzelne Bounded Contextsbetrachten. Das Modell des Besuchers kann innerhalb dieserDomänen jedoch unterschiedlich behandelt und dargestelltwerden. So kann ein Besucher im Bounded Context derRegistrierung mit den Attributen Name, Vorname, Firma,Anschrift, Zahlungsweise und angemeldete Tracks repräsentiertwerden. Im Bounded Context des Konferenzpassdrucks kann derBesucher durch die Attribute vollständiger Name, Twitter Handleund Jobtitel dargestellt werden. Im Gegensatz dazu sind

hinsichtlich des Besuchers im Kontext der Kapazitätsplanungprimär die Essenspräferenzen (Vegetarier oder nicht?) undSession-Interessen von Relevanz. Dieses Modell ist auch dafürgeeignet, unabhängige Datendarstellungen abzubilden, wobei esbesonders im Hinblick auf den Namen des KonferenzbesuchersPotenzial für geteilte Daten gibt. Idealerweise würden dieeinzelnen Bounded Contexts über ein Eventsystem miteinanderagieren.

Im Umfeld des Bounded Contexts hilft uns die so genannteContext Map dabei, die Interaktionen und Abhängigkeitenzwischen einzelnen Systemen, z. B. Microservices, zubeschreiben. Im Gegensatz zu den hinlänglich bekanntenBeschreibungsstilen für Liefer- und Leistungsbeziehungen, gehtdie Idee der Context Map jedoch weiter: Sie betrachtet, wieModelle von einem Kontext in den nächsten Kontext propagiertwerden. Anders formuliert: Anhand der Context Map kann maneinfach feststellen, wie die echten Abhängigkeiten zwischeneinzelnen Systemen/Microservices sind. Domain-driven Designsieht hierfür sieben Interaktionsarten vor:

Shared KernelCustomer/SupplierConformistAnticorruption LayerSeparate WaysOpen/Host ServicePublished Language

Abb. 1: Die Context Map hilft dabei, die Interaktionen und Abhängigkeiten zwischeneinzelnen Systemen zu beschreiben

Die Abhängigkeitsform des Shared Kernels besagt, dass sichTeams, die unterschiedliche Anwendungen entwickeln, einSubset des Domänenmodells teilen, wobei es hierbei irrelevantist, ob das Modell auf Code- oder auf Datenebene geteilt wird. Sokönnen bereits geteilte Tabellen in einer Datenbank dazu führen,dass die Teams mit Shared Kernel arbeiten. BeiCustomer/Supplier besteht eine Liefer- undLeistungsabhängigkeit hinsichtlich der Modelle zweier Teams,allerdings geht diese Abhängigkeit so weit, dass daskonsumierende Team, der Customer, ein Vetorecht im Hinblickauf das anbietende Team (Supplier) hat. Dies kann dazu führen,dass das Supplier-Team massiv vom Customer-Team anWeiterentwicklungen gehindert werden kann. Conformist istähnlich zu Customer/Supplier gelagert, allerdings hat hier daskonsumierende Team eine untergeordnete Rolle: Es passt seininternes Modell dem Modell des Supplier-Teams an.

Die bisherigen Interaktionsmuster adressieren eher enggekoppelte Systeme. Ein erster Schritt in Richtung loser Kopplungist der Anticorruption Layer. Hierbei besitzt ein System einededizierte Komponente oder Schicht, um ein externes Modell inein internes Modell zu übersetzten. Änderungen am externenModell ziehen sich somit nicht durch die gesamte Anwendung,

sondern können an einer dedizierten Stelle abgefangen werden.Die losest mögliche Kopplung zwischen zwei Systemen istSeparate Ways. Hierbei gibt es keinerlei Beziehungen zwischenden Systemen. Jedes Team kann somit seine eigene Lösung fürdie jeweilige Domäne finden. Eine klassische „SOA-Interaktionsform“ ist Open-/Host-Service, bei dem ein Systemspezielle Schnittstellen publiziert, die für externeKommunikation ausgerichtet sind. Meist wird hierbei auch miteinem Datentransfermodell gearbeitet.

Schlussendlich sieht Domain-driven Design noch einekonzeptionelle sprachliche Kopplungsform vor: die PublishedLanguage. Hierbei ist das Model in Form der UbiquitousLanguage festgelegt, und zwei Bounded Contexts halten sich anden in der Ubiquitous Language beschriebenen Kontrakt. Bei derPublished Language sollte man jedoch im Projekt darauf achten,dass dieses nicht plötzlich in Richtung eines abstraktenUnternehmensdatenmodells abdriftet.

Betrachtet man nun die gerade erwähnten Interaktionsformen,so kann man feststellen, dass es hierbei einen direkten Bezug zuConways Law gibt: Shared Kernel, Customer/Supplier undConformist sind primär Patterns, die eine sehr starke Kopplungund Kommunikation zwischen Teams erfordern. Auf der anderenSeite fördern Anticorruption Layer, Separate Ways, Open-/Host-Service und Published Language eine losere Kopplung und somitauch weniger Eins-zu-eins-Kommunikation zwischen den Teams.

Interne Bausteine für die interne AusgestaltungDas Kapitel zu internen Bausteinen (Internal Building Blocks) istder wohl bekannteste Teil aus Domain-driven Design. In diesemKapitel geht es um Entitäten, Value Objects, Aggregate oderServices, also um Patterns für die interne Ausgestaltung einesBounded Contexts bzw. Microservices. Entitäten stellen hierbeizentrale Geschäftsobjekte eines Domänenmodells dar. Sie habeneine konstante Identität und einen eigenen Lebenszyklus. ImGegensatz dazu sind Value Objects primär im Hinblick auf dieAusprägung ihrer Attribute von Interesse. Im Gegensatz zuEntitäten haben Value Objects auch keinen eigenständigenLebenszyklus. Dieser hängt immer vom Lebenszyklus der Entitätab, die das Value Object referenziert. Allerdings ist die

Entscheidungsfindung, ob ein Objekt nun als Entität oder ValueObject gehandelt werden soll, nicht immer eindeutig. Betrachtenwir beispielsweise eine Anschrift bestehend aus Name, Straße,Postleitzahl und Stadt. Im Kontext eines einfachen Onlineshopsnamens „Michaels Plattenladen“ wird die Anschriftwahrscheinlich nur für den Druck von Versandetiketten benötigt.Hier wäre eine Einordnung als Value Object korrekt, das an derEntität Bestellung als Versandadresse hängt. Auf der anderenSeite kann die Anschrift auch als Entität betrachtet werden; undzwar in einem Logistikkontext, bei dem auf Basis dieser zentralenEntität Auslieferungsrouten berechnet werden. Kurzum: Es hängtimmer vom (Bounded) Kontext ab.

Das interessanteste Pattern im Bereich der internen Bausteine istdas Aggregat, das Entitäten in fachlichen Teilbereichen gruppiert.Es wäre sehr unpraktikabel, wenn jede Entität wirklich eineneigenen Lebenszyklus hätte. Noch unstrukturierter wäre es,wenn jede Entität beliebige andere Entitäten referenzierenkönnte. Aggregate fassen fachlich zusammengehörige Entitätenzusammen und definieren in einem solchen fachlichen Blockeine so genannte Root-Entität. Diese Root-Entität hat zweiKerneigenschaften. Zum einen steuert sie den gesamtenLebenszyklus des Aggregats, inklusive der darin enthaltenenEntitäten. Zum anderen ist die Root-Entität die einzige Entität desAggregats, die von außerhalb eines Aggregats referenziertwerden darf.

Abb. 2: Aggregate fassen fachlich zusammengehörige Entitäten zusammen und definierenin einem solchen fachlichen Block eine so genannte Root-Entität

Aggregate sind wie Bounded Contexts hervorragend dafürgeeignet, die Granularität von Microservices zu bestimmen. EinMicroservice sollte minimal so groß wie ein Aggregat, maximalaber so groß wie ein Bounded Context sein.

Domain-driven Design sieht im Bereich der internen Bausteinenoch weitere Patterns vor. So werden Services verwendet, umGeschäftslogik zu kapseln, die mehrere Services und Aggregatebetrifft. Factories sind für das Erzeugen komplexerObjektgraphen verantwortlich und Repositories kapseln denDatenzugriff. Ein weiteres, vor allem im Bereich Microservicesinteressantes Konstrukt sind Events, die in Domain-driven Designals Auslöser für das Ausführen von Logik betrachtet werden.Mithilfe von Events lassen sich reaktive, lose gekoppelteMicroservices implementieren, die ohne Orchestrierungslogikauskommen.

Strukturieren und destillierenNatürlich werden Microservices und entsprechendeLandschaften wachsen, weshalb ein Team oder eine Organisationfrühzeitig darauf achten sollte, dass dieses Wachstum planvollverläuft. Das bedeutet allerdings nicht, dass rigide Entwicklungs-und Architektur-Guidelines eine natürliche Entwicklung im Keimersticken sollen. Im Gegensatz: Domain-driven Design sieht dankder Ideen der Evolving Order und den Responsibility Layers einegesunde Evolution vor. Die Evolving Order steht für einplanvolles Wachstum entlang von Leitplanken, die Freiheitsgradevorsehen. Weiterhin betont die Evolving Order, dass sich großeStrukturen primär an Bounded Contexts orientieren sollten. Alldiese Punkte werden häufig in der Microservices-Community alsetablierte Best Practices genannt.

Domain-driven Design sieht zudem so genannte ResponsibilityLayers vor, die dazu dienen, einzelne Bounded Contexts inunterschiedliche, fachlich getriebene Schichten zu strukturieren.So wird man in einer Microservices-Landschaft durchaus Servicesvorfinden, die beispielsweise kundenzentrisch sind. Danebenwerden Microservices existieren, die eher eine unterstützendeFachlichkeit besitzen. Als Beispiel hierfür kann man Batch-zentrische Dienste nennen.

Abschließend liefert uns Domain-driven Design noch

Anregungen für die Extraktion von Microservices aus einembestehenden Monolithen. Der Bereich der Destillation siehthierfür vier Schritte vor:

1. Identifikation einer Subdomäne2. Extraktion aus dem Kern3. Feinschliff der Extraktion4. Internes Refactoring

Diese vier Schritte werden durch zwei Dokumente begleitet: DasVision Statement beschreibt, was konkret in einem Microserviceenthalten ist und was nicht. Bei dieser Beschreibung geht es nichtum technische, sondern um rein fachliche Aspekte. Dietechnischen Aspekte finden im Destillation Document eineHeimat. Hier wird beschrieben, wie die Subdomäne bzw. der neuentstandene Microservice vom Rest der Anwendung technischgetrennt ist. An dieser Stelle geht es konkret umKommunikationsmuster, Schnittstellen undImplementierungsdetails.

FazitWie Sie sehen, passen Domain-driven Design und Microserviceshervorragend zusammen. Eric Evans lieferte in seinem Buch ausdem Jahre 2003, weit vor dem Microservices-Hype, sehr hilfreicheRatschläge und Patterns, die heute mehr Relevanz denn jebesitzen.

Michael Plöd ist Principal Consultant bei innoQ. Er hatüber zehn Jahre praktische Consultingerfahrung in denBereichen Softwareentwicklung und -architektur. Seinbesonderes Interesse gilt den BereichenSoftwarearchitekturen, Transformation/Modernisierung

von Anwendungen und Architekturen sowie polyglotte Persistenz.

Links & Literatur[1] Evans, Eric: „Domain-Driven Design. Tackling Complexity inthe Heart of Software“, Addison-Wesley, 2003

[2] Wolff, Eberhard: „Microservices. Grundlagen flexiblerSoftwarearchitekturen“, dpunkt.verlag, 2015

[3] Vernon, Vaughn: „Implementing Domain Driven Design“,

Addison-Wesley, 2013

DDD in der Praxis

Domain-driven Design imExperten-CheckSieben Experten für Domain-driven Design geben Einblicke inihre Praxiserfahrungen mit DDD.

Die DDD-ExpertenStefan Priebsch, Co-Founder der The PHP Consulting Company.

Oliver Gierke, Leiter des Spring-Data-Projekts bei Pivotal.

Henning Schwentner, Softwarearchitekt und Berater bei der WPS.

Dr. Carola Lilienthal, Seniorsoftwarearchitektin bei der Workplace SolutionsGmbH.

Michael Plöd, Principal Consultant bei innoQ.

Eberhard Wolff, Architekt, Berater und Fellow bei innoQ.

Lars Röwekamp, Gründer des IT-Beratungs- undEntwicklungsunternehmens open knowledge GmbH

Warum ist Domain-driven Design heute relevanter denn je?Carola Lilienthal: DDD ist aus zwei Gründen heute so relevant:Einerseits hat DDD mit Bounded Context ein Konzept, umFachdomänen voneinander abzugrenzen. Für Microservicesbraucht man genau diese Trennung. Andererseits erkennenimmer mehr IT-Leiter, Architekten und Entwickler, dass neueTechnologien nicht zu besser nutzbaren und wartbaren Systemenführen, sondern dass Software eine gute fachliche Modellierungbraucht. Auch hier bietet DDD viele hilfreiche Antworten. Beideszusammen macht DDD gerade heute sehr relevant.

Stefan Priebsch: Wir bauen heute – gerade im Web-Umfeld –deutlich komplexere Systeme als früher, mit ganz anderenQualitätszielen. DDD ist ein Ansatz, der für hinreichend komplexeSysteme gut funktionieren kann, von daher gibt es natürlich mitinsgesamt steigender Komplexität der Systeme auch mehr“Angriffsfläche” für Domain-Driven Design. Möglicherweise istDDD zur Zeit “nur” ein aktueller Trend, ich denke aber, dieTatsache, dass sich so viele Teams und Firmen in RichtungDomain-Driven orientieren ist auch ein Indikator dafür, dassandere Ansätze möglicherweise weniger gut funktioniert haben.

Eberhard Wolff: Viele Architekten erkennen durch denaktuellen Trend zu Microservices, wie wichtig der fachlicheSchnitt von Systemen ist. Genau dort hilft Domain-driven Design.Interessanterweise hat Eric Evans in seinem Buch “Domain-driven Design” neben der Architektur auch die Zusammenarbeitzwischen Teams beschrieben. Auch die Wechselwirkungzwischen Organisation und Architektur wird gerade durchMicroservices wieder aktuell.

Oliver Gierke: Das ist eine wirklich gute Frage. Das Buch hat sichja nicht plötzlich geändert. Ich glaube, dass das Revivalhauptsächlich damit zu tun hat, dass es seit einer gewissen Weileverbesserte technische Möglichkeiten gibt, bestimmte Konzeptedes Buches umzusetzen. Die fundamentalen Bausteine von DDD

wie Entitäten, Aggregate, Repositories usw. sind ja eigentlich injeder Architekturform umsetzbar. Nun ist es allerdings so, dass esunterschiedliche Grade gibt, in denen eine bestimmte Architekturzu allgemeineren Konzepten wie DDD passt, und umgekehrt, wiegut diese Konzepte eben zu den Konzepten der gewähltenArchitektur passen.

Zentraler Anknüpfungspunkt zur aktuellen Diskussion umMicroservices sind hierbei DDDs Bounded Contexts, die einenRaum kohärenter Begrifflichkeit innerhalb eines Systemsbeschreiben. Laut Eric Evans ist das zuallererst auf dieDomänensprache bezogen: Eine “Bestellung” meint etwas völligVerschiedenes, je nachdem, ob ich aus dem Blickwinkel“Versand” darauf schaue — dann sind Empfangsadresse undVerpackungsmaße interessant —, aus dem Blickwinkel“Rechnungsstellung” — dann interessieren michBestellpositionen und deren Steuersätze —, oder ausLagerhaltungssicht — hier interessieren Bestellpositionen undinsbesondere deren Anzahl. Diese Blickwinkel bilden nun dieKontexte, die voneinander isoliert werden sollten, aber trotzdemmiteinander in Beziehung zu setzen sind.

Die Kernfrage, die sich nun stellt, ist, wie genau man dastechnisch umsetzt. Wobei ich hier noch gar nicht dieModellierung von Entitäten oder ähnliches meine, sondern dastechnische Mittel, wie sich diese Kontexte in derSystemarchitektur abbilden. In einem eher monolithischenSystem finden sich hier auch Mittel und Wege, das zu tun, und ichhabe auch viele Systeme gesehen, die das mehr oder wenigererfolgreich umgesetzt haben.

Den neuen Aspekt, den eine Microservice-Architektur nun in dieDiskussion einbringt, ist die Idee, Systemgrenzen an den Grenzeneines Bounded Context zu ziehen, d.h. eine sehr direkteÜbersetzung des Konzepts aus DDD in die Systemarchitektur zuwählen. Diese Idee hat sehr weitreichende technische undorganisatorische Effekte, die zur Zeit ja sehr umfänglichdiskutiert werden. Ich denke jedoch, dass es eben genau dieserAspekt ist, der Entwickler und Architekten gerade dazu verleitet,das Buch wieder aus dem Regal zu holen und sich dem Themanoch einmal intensiver zu widmen.

Henning Schwentner: Domain-driven Design oder allgemeinerAnwendungsorientiere Softwareentwicklung ist immer wichtiggewesen und wird es auch weiter bleiben. Entscheidend ist dieErkenntnis, dass das Wichtige die Fachlichkeit und nicht dieTechnik ist. Software ist nie Selbstzweck sondern immer nurMittel zum Zweck. Und dieser Zweck ist es, den Benutzer bei ihrerArbeit zu unterstützen. Einen neuen Hype erlebt DDD derzeit,weil wir Entwickler durch den Microservices-Architekturstil dasKonzept der Bounded Contexts besser verstehen und endlichauch in der Praxis umsetzen können.

Michael Plöd: Einfach beantworten könnte man die Frage mitdem Satz: “Weil gutes fachliches Design immer wichtiger wirdund noch nie unwichtig war.” Aber schaut man unter die Haube,denke ich, dass durch den Trend in Richtung MicroservicesAbhängigkeiten, die sich im Bauch eines Monolithen versteckten,nun sichtbar werden. Kurzum: Implizite Abhängigkeiten undStrukturen werden plötzlich explizit, was natürlich ein gutesfachliches Design prominent in den Fokus der Aufmerksamkeitrückt.

Lars Röwekamp: In den ersten Jahren wurde DDD lediglich voneiner kleinen Gruppe “Interessierter” adaptiert, die es bereitsdamals verstanden haben, dass es bei der Entwicklung vonSoftware eher um die korrekte Umsetzung von Fachlichkeit alsum technologische Aspekte geht. Ein stets in sich konsistentesDomänen-Modell garantiert, dass es nicht zu unerwartetenSeiteneffekten kommen kann.

Durch die in der Vergangenheit meist strikte Trennung von Fach-und Entwicklungsabteilung war es bis dato nicht ganz trivial fürDDD, seine Trümpfe voll auszuspielen. Mit der Einführung vonagilen und cross-functional orientierten Teams hat sich dieAusgangssituation vor wenigen Jahren schlagartig geändert.Fachabteilung und Entwicklung rücken mehr und mehrzusammen. Der Entwickler mutiert – im positiven Sinne – vomTechnologielöser zum Fachentwickler.

Einen weiteren, wenn nicht sogar den entscheidenden Kick hatDDD durch den Siegeszug der Microservices erhalten. Denn nur,wenn ich es schaffe, Microservices fachlich sinnvoll undmöglichst unabhängig voneinander zu schneiden – in DDD

spricht man hier von einem „Bounded Context“ –, bekomme ichdie gewünschte lose Kopplung mit all seinen Vorteilen. Gelingtmir dies nicht, dann kommt an Ende ein “verteilter Monolith”heraus, also quasi das Worste Case Scenario der Software-Entwicklung.

DDD eignet sich vor allem für Projekte, die…… eine hinreichend komplexe Fachlichkeit haben. Interessanterweise unterschätzt manmeist, wie komplex sich eine Fachlichkeit darstellt, wenn man erst einmal genauerhinsieht. Ich habe das mal in einem Artikel anhand einer Pommesbude aufgezeigt. StefanPriebsch

… eine reichhaltige Fachlichkeit haben, also mehr als Daten erfassen, speichern undlöschen beinhaltet. Carola Lilienthal

… komplexe Geschäftslogik abbilden sollen. Eberhard Wolff

… eine Software entwickeln, die ihren Anwender bei seiner Arbeit unterstützen soll.Henning Schwentner

… anspruchsvolle Fachlickeit umsetzen müssen. Michael Plöd

… fachlich getrieben sind und somit von einem durchgehend in sich konsistentenDomänenmodell stark profitieren. Lars Röwekamp

Was sind die typischen Probleme bei der Umsetzung von DDD?Carola Lilienthal: DDD steht und fällt mit einem gutenVerständnis des Anwendungsgebiets. Sich dieses Verständnisanzueignen, fällt vielen Entwicklungsteams schwer. Einerseitshaben die Anwender keine Zeit, ihr Wissen weiterzugeben undden Entwicklern bei einem systematischen Verständnis zu helfen.Andererseits bevorzugen viele Entwickler technischeFragestellungen vor der Vertiefung in fachliche Details. Hiermuss ein echtes Umdenken stattfinden:

Die Entwickler müssen Freude daran entwickeln, Experten fürein Anwendungsgebiet zu sein.

Die Anwender müssen verstehen, dass die Software nur danneinen guten fachlichen Kern haben kann, wenn sie ihr Wissenumfänglich weitergeben und im gesamten Lebenszyklus desSystems zu Diskussionen bereit sind.

Stefan Priebsch: Entwickler denken meist eher technischorientiert und haben es daher schwer, stärker als bisher auf dieFachlichkeit zu fokussieren. Hinzu kommt, dass viele Entwicklerdie Anwender beziehungweise Fachabteilungen schon so

“erzogen” haben, dass diese eine sehr technische Sprache undDenkweise angenommen haben. Da wird beispielsweise ganzselbstverständlich von Datenbanktabellen gesprochen –eigentlich ein reines Implementierungsdetail, das den Anwendernicht interessieren sollte. Hand in Hand damit geht ein starkerCRUD-Fokus, den ich leider sehr oft erlebe. In einerdomänengetriebenen Welt kann es das Editieren einesDatensatzes an sich nicht geben, stattdessen muss man sichüberlegen, welche konkreten Geschäftsvorfälle eine “Änderung”motivieren. Viele Fachabteilungen neigen dazu, in denLimitierungen vorhandener Systeme zu denken, anstelle einenVorgang etwas abstrakter als Prozess zu sehen. Es ist daheroftmals schwierig, die richtigen Domänen-Experten zu finden, mitdenen man DDD richtig umsetzen kann.

Lars Röwekamp: Das größte Problem ist fast immer das Findeneiner gemeinsamen, fachlich motivierten Sprache zwischenEntwicklern und Fachexperten, in DDD „Ubiquitous Language“genannt. Dies klingt zwar trivial, ist aber für den Erfolg einesProjektes essentiell. Denn erst, wenn ich mich auf diese einegemeinsame Sprache (pro Fachdomäne) geeinigt habe, kann ichauch sicher sein, dass alle Beteiligten in den Diskussionen dasGleiche meinen. Gelingt dies nicht, sind Missverständnisse undsomit fachliche Fehler in der Software bzw. dem Domänen-Modell per Definition vorprogrammiert.

Nehmen wir einmal das Beispiel „Arzt“. Aus Sicht einesEntwicklers ist ein Arzt ein Mensch, der andere Menschen in(s)einer Praxis behandelt und damit Geld verdient. Aus Sichteines Fachexperten sind dies aber unter Umständen völligverschiedene Dinge. Denn für den Fachexperten gibt es einenBehandler, einen Abrechner und einen Praxisbetreiber. Diesekönnen ein und dieselbe Person sein, müssen es aber nicht. UnterUmständen sind es noch nicht einmal reale, sondern nurjuristische Personen. Erst die Differenzierung in der Sprache unddas damit verbundene Nutzen der Fachtermini stellt sicher, dassbei der Analyse der Fachlichkeit die Fachexperten und dieEntwickler nicht aneinander vorbeireden. Dies wiederum ist dieGrundvoraussetzung für korrekte Software.

Eberhard Wolff: Die Building Blocks wie Entity, Value Object,Repository usw. sind meistens bekannt – und auch intuitiv leicht

zu erfassen. Aber Strategic Design und Bounded Context kennenviele nicht. Die Idee, dass selbst grundlegende Geschäftsobjektewie Kunde oder Bestellung nicht allgemeingültig für ein ganzesUnternehmen definiert werden können, überrascht immer nochviele. Daher werden diese Patterns auch noch nicht breit genutzt.Gerade Strategic Design wirklich gut umzusetzen, erfordert alsoein grundlegendes Umdenken.

Oliver Gierke: DDD ist ein weites Feld und betrifft sehr vieleAspekte des Softwareentwicklungsprozesses. Auf technischerEbene sowohl im Bereich Makroarchitektur — welche Kontextegibt es? Wie stehen diese zueinander in Beziehung? Wie werdendiese abgebildet? usw. — als auch in einem Bereich irgendwozwischen Mikroarchitektur und Design.

In letzterem Bereich, in dem vor allem die fundamentalenBausteine wie Entitäten, Aggregate usw. in den Fokus geraten,gibt es nun erhebliche Berührungspunkte mit Frameworks allerArt. Hier ist es leider oft so, dass diese bestimmte Designvorgabenmachen, die eine Umsetzung der DDD-Konzepte erschweren. DerKlassiker hierbei ist, dass JPA als ORM-Technologie, Default-Konstruktoren voraussetzt und sehr stark auf Mutabilität setzt, sodass es nur mit erheblichem Aufwand möglich ist, wirklichBusinessregeln in Entitäten umzusetzen. Java als Spracheerfordert sehr viel Aufwand für die Implementierung von ValueObjects. Hinzu kommt, dass es viel Technologie gibt, die einfachschlicht falsche Anreize setzt und vorlebt, @Email String emailwäre ein adäquater Ersatz für einen dezidierten TypEmailAddress.

Mein Punkt ist, dass man als Entwickler auf derUmsetzungsebene oft mit erheblichem MehraufwandUnzulänglichkeiten von Technologie ausgleichen muss, was oftdazu führt, dass man Konzepte und Ideen aus DDD nur halbumsetzt und damit einen großen Teil des Mehrwertesverschenkt.

Henning Schwentner: Wir Entwickler haben immer Lust auf dieneuesten Trends, Frameworks, Programmiersprachen usw. Wirwollen gerne all dieses Neue ausprobieren und in unsere Projekteeinbauen. Das ist gut und richig, aber wir dürfen nicht derVersuchung erliegen, uns nur technik- und selbstverliebt um die

neuesten Technologien zu drehen. Wir müssen ein gutes undbelastbares Fachmodell bauen, denn nur so können wir unserenAnwender bei ihrer Arbeit unterstützen. Und das ist unsereHauptaufgabe; alles andere ist sekundär.

Oft wird technischer und fachlicher Code gemischt. Das führt zuProblemen, weil Fachlichkeit und Technik sich inunterschiedlichen Zyklen ändern. Wir wollen unseren fachlichenCode stabil halten und nicht ändern müssen, weil es z.B. eineneue Oberflächentechnologie gibt.

Michael Plöd: Ich sehe im Praxiseinsatz primär zweiUmsetzungsprobleme. Erstens verstehen viele Teams diegrundsätzlichen Building Blocks wie Value Objects, Repositoriesoder Entities, aber ich stelle immer wieder fest, dass das ValueObject viel zu selten zum Einsatz kommt und dass geradeAggregate im Laufe von Projekten einer “Architektur-Korrosion”zum Opfer fallen. Des Weiteren werden die Werkzeuge desContext Mappings aus Strategic Design gerade beiTransformationsplanungen vernachlässigt. Gerade eineSkizzierung einer bestehenden Landschaft, die über einfacheLiefer- und Leistungsbeziehungen hinausgeht, findet häufig nichtoder nur unzureichend statt, was schade ist, weil dieKlassifizierung mit Hilfe der Context Mapping Patterns vielewertvolle Informationen liefert.

Von DDD sollte man die Finger lassen, wenn…… man lediglich Anwendungen zur reinen Verwaltung von Entitäten (a.k.a. CRUD-Anwendung), wie z.B. administrative Oberflächen, baut. Lars Röwekamp

… man kein Interesse an Diskussionen über die Fachlichkeit hat und am liebstenTechnologien ausprobiert. Carola Lilienthal

… man nur an kurzfristigem Erfolg interessiert ist und beispielsweise Projektfortschrittanhand von erstellten Listenansichten und Masken zur Änderung von Datensätzenmessen möchte. Stefan Priebsch

…das Projekt eine niedrige fachliche Komplexität hat. Eberhard Wolff

… man sich nicht mit der Fachlichkeit beschäftigen möchte. Und dann sollte maneigentlich von der Softwareentwicklung im Ganzen die Finger lassen. HenningSchwentner

… nicht das ganze Projektteam mitspielt oder wenn man einfach CRUD-Anwendungenentwickelt. Michael Plöd

Wie kann DDD in die Praxis umgesetzt werden?

Carola Lilienthal: Anwender und Entwickler müssen sich zuBeginn der Entwickler sehr oft treffen und über die Fachlichkeitdiskutieren. Dabei sollten die Entwickler Schritt für Schritt einimmer feinere Modell der Fachsprache entwerfen, das sie mit denAnwender dann hinterfragen. Hat man hier einen ersten gutenStand erreicht, kann mit der Implementierung begonnen werden.Wichtig ist dabei, dass auch tatsächliche die Begriffe derAnwendungswelt verwendet werden.

Stefan Priebsch: Vergesst erst einmal alles, was Ihr jemals überTechnik und Software-Entwicklung gelernt habt. Setzt euchstattdessen mit der Fachabteilung (den “Domänen-Experten”)zusammen, verteilt die Rollen und spielt den Ablauf, den ihrgerade betrachtet, als eine Art Pen-and-Paper-Rollenspiel durch.Versucht nicht, alle Probleme auf einmal zu lösen, sondernnehmt euch einen häufig auftretenden Fall vor. Dann geht daran,das Pen-and-Paper-Rollenspiel in Software umzusetzen undersetzt damit einen Teil der vorhandenen Legacy-Software.

Lars Röwekamp: Mein Pro-Tipp No. 1 heißt “üben, üben, üben.”Das klingt trivial, ist aber nach unseren Erfahrungen derSchlüssel zum Erfolg. Wichtig dabei ist, dass sich Fachexpertenund Entwickler immer wieder an einen Tisch setzen und über dieumzusetzende Fachlichkeit und das aktuelle Domänen-Modelldiskutieren. Dabei wird es immer wieder zu neuen Erkenntnissenund damit einhergehend zu einem beidseitig besserenVerständnis der fachlichen Domäne kommen. Natürlich könnendiese Erkenntnisse dazu führen, dass Änderungen ambestehenden Code notwendig sind. Aber das ist auch gut so. Dennum ehrlich zu sein, wäre es ja schon verwunderlich, wenn sichdie Sicht auf die Fachlichkeit ändert, der zugehörige Code aberunverändert bleibt, denn dann hätte ich bereits vorher etwasfalsch gemacht.

Eberhard Wolff: Bei meinen Trainings setze ich darauf, konkreteBeispiele nach DDD praktisch entwerfen zu lassen. Dabeifokussiere ich jeweils auf eine Ebene von DDD – beispielsweiseBuilding Blocks oder Strategic Design. Die Ergebnisse diskutierenwir dann, und ich gebe ebenfalls Feedback – das erleichtert denStart.

Oliver Gierke: Hier würde ich vermutlich analog zur Aufteilung

des Buches zwei große Bereiche unterscheiden: den makro-architektonischen in Bezug auf die Kontextaufteilung und deneher mikro-architektonischen in Bezug auf die Umsetzung unddie verwendeten Technologien.

In ersterem plädiere ich üblicherweise dazu, nicht mitÜberaufteilung zu beginnen. Zum einen gibt es bei wenigErfahrung mit großen Systemlandschaften vielerlei neueHerausforderung wie z.B. das Monitoring dieser Landschaft, dieerst einmal gelöst werden wollen. Hier ist man dann oft mit ehertechnischen Aspekten beschäftigt — etwas, was Entwicklernüblicherweise großen Spaß bereitet, wobei man dann daraufachten muss, sich nicht darin zu verlieren. Sonst baut manschlussendlich eher Framework als Fachlichkeit.

Der eigentlich viel zentralere Punkt ist meiner Meinung nachjedoch der Fakt, dass gerade im frühen Stadium eines Projektesnoch vergleichsweise wenig Wissen über die Domäne besteht.D.h. man lernt zu diesem Zeitpunkt besonders viel über sie, undes ergibt sich üblicherweise regelmäßiger, recht umfangreicherÄnderungsbedarf. In einem eher monolithischen System sindÄnderungen einfacher zu realisieren als in einem sehr starkverteilten. In diesem Zusammenhang kann es also durchaus vonVorteil sein, zwei oder drei Kontexte, über deren Grenzen undAusgestaltung man sich noch nicht ganz im Klaren ist, in einemSystem zu halten, bis man eine gewisse Reife erreicht. Wenndieses System dann sauber strukturiert ist, lässt es sich auch ineinem späteren Schritt noch gut separieren, sollte es notwendigwerden, das zu tun.

Auf der anderen Seite ist es jedoch auch schwierig, mit nur einemSystem zu starten. Vor allem, da man damit die Kosten, die eineAufteilung später mit sich bringt, auf einen späterenProjektzeitpunkt verschiebt. Einem Zeitpunkt, an dem man sicheigentlich nicht mehr grundsätzlich überlegen will, wie Systemejetzt plötzlich miteinander kommunizieren sollen, wie man dieSystemlandschaft überwacht, usw.

Henning Schwentner: In der Praxis enstehen leider zu häufigblutleere Fachmodelle. Da wird dann schon ein Datensack (d.h.eine Klasse, die nur Getter und Setter hat) als Entity bezeichnet.Was wir aber eigentlich wollen, sind reichhaltige Fachmodelle.

Und die bestehen aus Klassen mit fachlichen Operationen. Wieerhalte ich solche fachlichen Operationen? Dazu empfiehlt essich, sich den Umgang der Entity in der Wirklichkeitanzuschauen. Oft ist es eine gute Idee, aus jeder Umgangsformder echten Entity eine Methode an der Entity-Klasse zu machen.So entsteht ein Modell und eine Software, die die Realitätabbilden. (Demjenigen, der sich tiefer dafür interessiert empfehleich, sich den Werkzeug&Material-Ansatz näher anzuschauen, z.B.unter www.wam-ansatz.de).

Michael Plöd: Ich finde es gut, gerade Anfangs bei den BuildingBlocks oder bei Strategic Design strikt nach Lehrbuch zu arbeitenund keine Ausnahmen, beispielsweise beim Entwurf von ValueObjects oder Aggregaten zuzulassen. Weiterhin finde ich kleineModellierungsworkshops, in denen die Projektteilnehmer DDD-Praktiken üben, wertvoll. Der Begriff “Projektteilnehmer”inkludiert hier zudem ganz klar auch fachliche Teammitglieder,denn ohne Verständnis von DDD beim Fachbereich wird sich dasEntwicklungsteam schwer tun, DDD erfolgreich zu etablieren.

Microservice-Architekturen profitieren von DDD-Konzepten,weil ……das Konzept Bounded Context hilft, einzelne Microservices abzugrenzen. CarolaLilienthal

… der Bounded Context aus DDD eine natürliche Grenze für einen Microservice bildetund so die größtmögliche Unabhängigkeit eines Services zu seinen Nachbarn garantiert.Lars Röwekamp

… weil beide Ansätze die Idee von starken Grenzen (Boundaries) teilen und DDD einemWerkzeuge an die Hand gibt, innerhalb solcher Grenzen Software zu entwerfen, die insich abgeschlossen funktioniert. Stefan Priebsch

… Strategic Design und Bounded Context die fachliche Aufteilung eines Systems inMicroservices erleichtern. Eberhard Wolff

… sie ohne das Strategic Design von DDD nicht denkbar sind. Henning Schwentner

… DDD gerade im Umfeld von Strategic Design wertvolle Hilfsmittel zur Modellierungvon Microservices liefert (Bounded Context, Context Map) und weil DDD durch dieBuilding Blocks bewährte Patterns zum Implementierung einzelner Microservices bereithält. Michael Plöd