#Domain-driven Design

Grundlegendes Domain-driven Design für Microservices

Der Trend zu kleineren Softwaresystemen stellt Entwickler beim Design dieser Systeme vor neue Herausforderungen: In welche Teile separiere ich meine Domäne? Wie referenziere ich logisch gleiche Artefakte eines Gesamtsystems in den einzelnen Teilsystemen? In seiner Session von der W-JAX 2016 stellt Oliver Gierke die im Kontext von Microservices grundlegendsten und wichtigsten Konzepte des Domain-driven Designs vor. Er erläutert zudem, warum gerade diese es sind, die in einer Landschaft kleiner Systeme so wichtig sind.

Domain-driven Design in Aktion: Mehr Dynamik mit Event Storming

Traditionelle Anforderungsworkshops ohne Beteiligung der Entwicklung erfüllen den heutigen Time-to-Market-Anspruch nicht mehr. Mit dem vor einigen Jahren eingeführten User Story Mapping wurde das immerhin schon einmal besser. Was ist aber, wenn das Grundverständnis der Fachdomäne im Team noch nicht hergestellt ist, sodass das Story-Schreiben schwerfällt? Hier kann Event Storming helfen, eine Workshopmethode aus der Domain-driven-Design-Familie. Fachexperten und IT-Leute verbrauchen dabei enorm viele Post-its, um ein gemeinsames Verständnis einer Fachdomäne zu bekommen.

Grundlegendes Domain-driven Design: Wie Microservices-Architekturen (nicht) von DDD profitieren

Domain-driven Design – kurz DDD – erfährt in der aktuellen Diskussion um Softwarearchitektur eine hohe Aufmerksamkeit. Das Anfang der 2000er geprägte Konzept gilt insbesondere als eine der Grundlagen-Theorien für Microservices-Architekturen. Wir haben uns mit W-JAX Speaker Oliver Gierke (Pivotal) über die Herausforderungen unterhalten, die bei der Umsetzung von DDD in die Praxis zu bewältigen sind.

„Ich bin keinesfalls der Meinung, dass man immer Microservices einsetzen sollte“

Microservices oder Software-Monolithen – über diese Architekturfrage wird momentan teils kontrovers diskutiert. Wir haben Stefan Tilkov, Principal Consultant bei der innoQ und Sprecher auf dem Software Architecture Summit, um einen Beitrag zur Debatte gebeten. Dabei kommt auch das Problem in den Blick, wie Legacy-Anwendungen an moderne Architektur-Ansätze herangeführt werden können.

„Man braucht einen Tag, um von DDD zu profitieren, aber ein ganzes Leben, um es zu meistern“ [Interview mit Jimmy Nilsson]

In Rahmen unseres Themen-Dossiers zu Domain-driven Design haben wir mit Jimmy Nilsson gesprochen, der der DDD-Bewegung mit seinem Buch „Applying Domain-Driven Design and Patterns“ wichtige Impulse verliehen hat. Was war und ist an DDD so inspirierend? Wie stehen DDD und Microservices zueinander? Welche aktuellen Architektur-Trends sollten wir im Auge behalten?

DDD versus DSL: Was Domain-driven Design mit domänenspezifischen Sprachen zu tun hat

Um Fachabteilungen besser mit der Software-Entwicklung zu verbinden, kommen domänenspezifische Sprachen (DSLs) zum Einsatz, die speziell für ein bestimmtes Problemfeld entworfen werden. Die Idee dabei: DSLs können direkt durch Domänenspezialisten ohne tiefgreifendes IT-Wissen manipuliert werden. Auch im Ansatz des Domain-driven Design steht ein Domänen-Modell im Zentrum des Entwicklungsprozesses; auch hier ist das Ziel, die Fachlichkeit in den Fokus der Software-Entwicklung zu stellen.

  • 1
  • 2