Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices lieben Domain Driven Design (Deutsch)

Microservices lieben Domain Driven Design (Deutsch)

Zweifelsohne kann das Buch "Domain Driven Design" von Eric Evans als "Muss" für Software Architekten und Entwickler betrachtet werden. Die dort geschilderten Ideen sind heute im Kontext von Trends wie Microservices relevanter denn je. Dabei gilt es jedoch zu berücksichtigen, dass Domain Driven Design nicht einfach nur auf Aggregate, Entitäten und Services zu reduzieren ist und dass es viel tiefergehende Zusammenhänge zwischen DDD und Microservices wie den Bounded Context gibt.
An dieser Stelle setzt der Vortrag an: wir werden Schritt für Schritt erkunden, wie uns die Ideen und Patterns beim Aufbau und Design von Microservice Landschaften helfen. Des Weiteren werden wir betrachten wie wir mit Hilfe von Domain Driven Design eine bestehende Landschaft in Richtung von Microservices migrieren können.

Link zu Beispiel Projekt: https://github.com/mploed/ddd-strategic-design-spring-boot

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

July 07, 2016
Tweet

More Decks by Michael Plöd

Other Decks in Technology

Transcript

  1. Microservices <3 Domain Driven Design Michael Plöd - innoQ
 @bitboss

  2. Disclaimer Michael Plöd - innoQ
 @bitboss Die meisten dieser Ideen

    stammen nicht von mir sondern aus Eric Evans herausragendem Buch Domain Driven Design. Dieses Buch möchte ich jedem Zuhörer meines Vortrags empfehlen. Ich übernehme die englischen Bezeichnungen aus Erics Buch im Sinne der Ubiquitous Language (Stichwort: Anglizismen)
  3. D D D in Microservices Der Zusammenhang von DDD und

    Microservices geht über Bounded Contexts hinaus Bei DDD geht es um mehr als nur um Aggregate, Entitäten und Services
  4. Domain Driven Design hilft uns im Hinblick auf Microservices in

    vier Bereichen Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
  5. Strategic Design Strategic Design besteht aus Bounded Context Context Map

    Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language
  6. Strategic
 Design Bounded Context Jede anspruchsvolle Domäne besteht aus mehreren

    Bounded Contexts Jeder Bounded Context enthält sein Model und ggf weitere Contexts Der Bounded Context ist zudem eine Grenze um die Gültigkeit eines Models Animation verfeinern
  7. Strategic
 Design Bounded Context Beispiel Anmeldung Event
 Management Badges Kunde

    Name Zahlungsart Adresse Firma Session Registrierungen Essenspräferenzen Name Job Titel Twitter Handle
  8. Strategic
 Design Bounded Context Example Anmeldung Event
 Management Badges Name

    Zahlungsart Adresse Firma Session Registrierungen Essenspräferenzen Name Job Titel Twitter Handle Jeder Bounded Context hat sein eigenes Model eines Kunden Dies ist ein wichtiger Enabler für unabhängige Microservices Bitte beachten Sie den Namen des Kunden, vielleicht ein Anlass für geteilte Daten
  9. Strategic Design Strategic Design besteht aus Bounded Context Context Map

    Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language
  10. Context Map Strategic
 Design Der Bounded Context an sich liefert

    noch keinen Überblick über ein System Durch die Einführung einer Context Map beschreiben wir, wie sich Models propagieren Die Context Map ist somit eine gute Ausgangsbasis für künftige Transformationen
  11. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language
  12. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Zwei Teams teilen sich ein Subset eines Domain Models inklusive Code und ggf. der Datenbank. Der Shared Kernel wird häufig auch als Kerndomäne bezeichnet.
  13. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Es gibt eine Kundenbeziehung zwischen zwei Teams. Das konsumierende Team ist Kunde mit häufig weitreichendem Einfluss (z.B. Vetorecht).
  14. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Das konsumierende Team passt sein Model dem Model des Dienstanbieters an. Es findet keine Übersetzung des Models statt. Das konsumierende Team hat zudem kein Vetorecht. Achtung vor Propagation von schlechten Models!
  15. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Der Anticorruption Layer ist eine Komponente, die das Model eines Clients von dem eines anderen Systems isoliert. Üblicherweise geschieht dies über eine Model-Transformation.
  16. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Es gibt keine Verbindung zwischen den Bounded Contexts von Systemen. Dies erlaubt den Teams unabhängig voneinander Lösungen zu finden und auszurollen.
  17. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Jeder Bounded Context bietet ein definiertes Set an Services / Funktionalität nach aussen hin an. Jedes konsumierende System kann über diese integrieren.
  18. Strategic
 Design Context Map - Patterns Shared Kernel Customer /

    Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Die Published Language is relativ ähnlich zum Open / Host Service. Allerdings erfolgt die Model Abstraktion über die Ubiquitous Language.
  19. Strategic
 Design Context Map - Warum? Baufi Antrag Kredit Entschei-

    dung Scoring Schufa Auskunft CRM Aktuell sehen wir hier nur
 Liefer- und Leistungs-
 beziehungen
  20. Strategic
 Design Context Map Baufi Antrag Kredit Entschei- dung Scoring

    Schufa Auskunft CRM U D D D D U U U C
 F O
 H
 S C
 U
 S O
 H
 S O H S A C L S K S K
  21. Strategic
 Design Context Map: Propagation Baufi Antrag Scoring Schufa Auskunft

    D D U U C
 F O
 H
 S Kredit Entschei- dung D U C
 U
 S O
 H
 S CRM U D O H S A C L S K S K
  22. Strategic
 Design Context Map: Propagation D D U C
 F

    Schufa Auskunft U O
 H
 S Baufi Antrag Scoring S K S K InfoScore
 Auskunft U O
 H
 S D A C L
  23. Unabhängigkeit Enge Kopplung Strategic
 Design und Conway’s Law Shared Kernel

    Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Kommunikation
  24. Domain Driven Design hilft uns im Hinblick auf Microservices in

    vier Bereichen Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
  25. Building Blocks helfen uns beim Entwurf der Interna eines Bounded

    Contexts Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services Repositories
  26. Building
 Blocks Entities Entities stellen die Kern Business Objekte einer

    Domäne dar Jede Entity hat eine konstante Identität Jede Entity hat einen eigenen Lebenszyklus Kunde Kredit Antrag Shipment
  27. Building
 Blocks Value Objects Value Objects haben keine eigenen Identität,

    es zählt die Ausprägung der Attribute Value Objects haben keinen Lebenszyklus, er hängt von der referenzierenden Entität ab Value Objects sind sehr wertvoll für das Domänen Modell Farbe Währungs betrag Kunde
  28. Building
 Blocks Ist „Kunde“ eine Entity der 
 ein Value

    Object Grundsätzlich hängt diese Entscheidung vom Bounded Context ab. Kunde Beispiel: Ein Kunde ist in einer CRM-Anwendung sicherlich eine Entität wohingegen er in der Anwendung für die Badges eher ein Value Object ist.
  29. Building
 Blocks Aggregates Unterschätze niemals die Macht des Aggregates

  30. Building
 Blocks Aggregates <Entity> Selbstauskunft <ValueObject> Adresse <ValueObject> TilgungsDetails <Entity>

    Kredit <Entity> Kunde <Entity> KreditAntrag <Root Entity> <Root Entity> Aggregate gruppieren Entitäten. Die Root-Entity steuert den Zugriff und den Lebenszyklus des Objektgraphen.
  31. Building
 Blocks Factories, Services, 
 Repositories Aggregates Entities Value Objects

    Factories Services Repositories Factories übernehmen die Instantiierung von Entities und Aggregates Repositories sind für Datenzugriff zuständig Services implementieren Fachlogik, die mehrere Entities und Aggregate betrifft
  32. Domain Driven Design hilft uns im Hinblick auf Microservices in

    vier Bereichen Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
  33. Large Scale Structure hilft bei der Evolution der Microservice Landschaft

    Evolving
 Order Large Scale
 Structure System
 Metaphor Resposibility
 Layers
  34. Large
 Scale
 Structure Evolving Order Job Title: 
 Chief Ivory

    Tower Architect Rigide Development Guidelines Unflexible Architektur
 
 Klare Regeln für jedes kleine Detail „Ich brauche nur billige Entwickler und übernehme das Denken für Sie“
  35. Large
 Scale
 Structure Evolving Order Entwickler Team System is zu

    komplex Wir müssen uns darauf fokussieren, die Regeln einzuhalten 
 Wir benötigen Workarounds um die Regeln zu umgehen
  36. Ziemlich ähnlich zu jedem Microservice „Pitch“? Large
 Scale
 Structure Evolving

    Order Evolving
 Order Grosse Strukturen sollten sich natürlich entwickeln Diese Strukturen sollten entlang der Bounded Contexts anwendbar sein Aber, es sollte einige praktische Constraints geben.
  37. Large
 Scale
 Structure Responsibility Layers Registration Event
 Management Badges Mailings

    Speakers Jeder Microservice ist entlang eines Bounded Context entworfen Innerhalb der Microservices strukturiert man mit den Building Blocks Allerdings sollte man zudem Microservices entlang ihrer Zuständigkeiten anordnen
  38. Domain Driven Design hilft uns im Hinblick auf Microservices in

    vier Bereichen Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
  39. Destillation hilft uns bei der Extraktion von Microservices aus einem

    Monolithen Destillation
  40. Destilla-
 tion Identifikation der Kerndomäne Destillation Document Beschreibt den Extraktionsvorgang

    Vision Statement Definiert was Bestandteil der Kerndomänen ist und was nicht
  41. Destilla-
 tion Extraktion von Subdomänen Identifikation der Subdomäne Extraktion Saubere

    Trennung Internes Refactoring
  42. Microservices Domain Driven Design Strategic Design (Internal) 
 Building Blocks

    Large Scale
 Structure Destillation <3
  43. Vielen Dank! <3 Michael Plöd - innoQ
 @bitboss