Microservices lieben Domain Driven Design (Deutsch)

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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)

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Domain Driven Design hilft uns im Hinblick auf Microservices in vier Bereichen Strategic Design (Internal)   Building Blocks Large Scale  Structure Destillation

Slide 5

Slide 5 text

Strategic Design Strategic Design besteht aus Bounded Context Context Map Shared Kernel Customer /   Supplier Conformist Anticorruption  Layer Separate Ways Open / Host   Service Published   Language

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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).

Slide 14

Slide 14 text

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!

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Domain Driven Design hilft uns im Hinblick auf Microservices in vier Bereichen Strategic Design (Internal)   Building Blocks Large Scale  Structure Destillation

Slide 25

Slide 25 text

Building Blocks helfen uns beim Entwurf der Interna eines Bounded Contexts Aggregates (Internal)   Building Blocks Entities Value Objects Factories Services Repositories

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

Building  Blocks Aggregates Unterschätze niemals die Macht des Aggregates

Slide 30

Slide 30 text

Building  Blocks Aggregates Selbstauskunft Adresse TilgungsDetails Kredit Kunde KreditAntrag Aggregate gruppieren Entitäten. Die Root-Entity steuert den Zugriff und den Lebenszyklus des Objektgraphen.

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Domain Driven Design hilft uns im Hinblick auf Microservices in vier Bereichen Strategic Design (Internal)   Building Blocks Large Scale  Structure Destillation

Slide 33

Slide 33 text

Large Scale Structure hilft bei der Evolution der Microservice Landschaft Evolving  Order Large Scale  Structure System  Metaphor Resposibility  Layers

Slide 34

Slide 34 text

Large  Scale  Structure Evolving Order Job Title:   Chief Ivory Tower Architect Rigide Development Guidelines Unﬂexible Architektur    Klare Regeln für jedes kleine Detail „Ich brauche nur billige Entwickler und übernehme das Denken für Sie“

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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.

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Domain Driven Design hilft uns im Hinblick auf Microservices in vier Bereichen Strategic Design (Internal)   Building Blocks Large Scale  Structure Destillation

Slide 39

Slide 39 text

Destillation hilft uns bei der Extraktion von Microservices aus einem Monolithen Destillation

Slide 40

Slide 40 text

Destilla-  tion Identifikation der Kerndomäne Destillation Document Beschreibt den Extraktionsvorgang Vision Statement Deﬁniert was Bestandteil der Kerndomänen ist und was nicht

Slide 41

Slide 41 text

Destilla-  tion Extraktion von Subdomänen Identiﬁkation der Subdomäne Extraktion Saubere Trennung Internes Refactoring

Slide 42

Slide 42 text

Microservices Domain Driven Design Strategic Design (Internal)   Building Blocks Large Scale  Structure Destillation <3

Slide 43

Slide 43 text

Vielen Dank! <3 Michael Plöd - innoQ  @bitboss