Prinzipien DDD

Prinzipien DDD

Ubiquitous Language

Prinzipien DDD

Fachlichkeit first

Hexagonale Architektur

Hexagonale Architektur

Wichtigste Punkte

• Domäne ohne Abhängigkeiten
• Äußere Schichten dürfen Abhängigkeiten zu inneren haben
• Aktive Adapter dürfen nicht direkt auf passive Adapter zugreifen
• Ports und Adapter für jede externe Kommunikation

Hexagonale Architektur

Zusammenfassung

• Gut bei sehr viel Fachlichkeit
• Mehreren parallelen Eingangs-/Ausgangskanälen
• Klare Vorgaben
• Viele Schichten, viel Code, viel Aufwand Pfade zu verfolgen (Debugging, Weiterentwicklung)
• Teilweise Herausforderungen bei der Performanz für passive Adapter
• Man braucht keine fachlichen Paketstrukturen (-;

Hexagonale Architektur

Erfüllung DDD-Prinzipien

• Kern: ++
• Use-Case-Gedanke: ++
• Paketstruktur: -- bis +
• Schnittstellenebene: -- bis +
• Isolation der Bounded-Contexts: -- bis ?

Onion Architektur

Onion Architektur

Wichtigste Punkte

• Domäne bildet den Kern
  • Hier wird die Businesslogik implementiert
• Äußere Schichten dürfen Abhängigkeiten zu inneren haben
• Äußere Schichten nutzen Infrastruktur
• Externe Kommunikation findet in der äußersten Schicht statt
• Schichten idealerweise in einzelnen Maven-/Gradle-Modulen

Onion Architektur

Zusammenfassung

• Ok wenn "viel" fachliche Aktionen vorhanden
• Hubs mit mehreren parallelen Eingangs-/Ausgangskanälen
• Klare Vorgaben
• Viele Schichten, viel Code, viel Aufwand Pfade zu verfolgen (Debugging, Weiterentwicklung)
• Auch hier: Man braucht keine fachlichen Paketstrukturen (-;

Onion Architektur

Erfüllung DDD-Prinzipien

• Kern: ++
• Use-Case-Gedanke: o
• Paketstruktur: -- bis o
• Schnittstellenebene: - bis +
• Isolation der Bounded-Contexts: -- bis ++

Clean Architektur

Clean Architektur

Wichtigste Punkte

• Analog zu Onion
• Fachlichkeit soll einem "anschreien" (Screaming Architecture)
• "Entities" statt "Core"
  • Hier wird die Businesslogik implementiert
• Orchestrierung in Use-Cases (nicht Services)

Domain-Based Architektur

Domain-Based Architektur

Wichtigste Punkte

• Entities bildet den Kern
  • Hier wird die Businesslogik implementiert
• Ein Bounded-Kontext liegt in einem Java-Paket
  • Inkl. allgemeingültiger Services/Repositories
• Es wird ein schmales Interface exportiert
  • "Package-lokal" ist Default-Sichtbarkeit
• Externe Kommunikation wird nicht in der Domäne implementiert (Adapter)

Domain-Based Architektur

Zusammenfassung

• Wenig Overhead
• Gute Navigierbarkeit
• Praktisch bei mehreren Bounded-Kontexten
  • größerer Microservice
  • SCS
• Mist: fachlichen Paketstrukturen (-;

Domain-Based Architektur

Erfüllung DDD-Prinzipien

• Kern: ++
• Use-Case-Gedanke: ++
• Paketstruktur: o bis ++
• Schnittstellenebene: o bis +
• Isolation der Bounded-Contexts: o bis ++

Spring Modulith Architektur

Spring Modulith Architektur

Wichtigste Punkte

• Entities bildet den Kern
  • Hier wird die Businesslogik implementiert
• Ein Bounded-Kontext liegt in einem Java-Paket
  • Inkl. allgemeingültiger Services/Repositories
• Es wird ein schmales Interface exportiert
  • "Package-lokal" ist Default-Sichtbarkeit
• Externe Kommunikation wird nicht in der Domäne implementiert
  • Adapter
  • Domänen-Events
• Support für Integration-Tests je Bounded-Context

Domain-Based Architektur

Zusammenfassung

• Wenig Overhead
• Gute Navigierbarkeit
• Praktisch bei mehreren Bounded-Kontexten
  • größerer Microservice
  • SCS
• Mist: fachlichen Paketstrukturen (-;

Domain-Based Architektur

Erfüllung DDD-Prinzipien

• Kern: ++
• Use-Case-Gedanke: ++
• Paketstruktur: + bis ++
• Schnittstellenebene: o bis +
• Isolation der Bounded-Contexts: + bis ++