Hexagonal / Clean / Onion - Architektur

Das ist doch alles das Selbe!

... oder?

… alles das Gleiche!

Es gibt viele Gemeinsamkeiten, aber auch Unterschiede.

Die sind in der Praxis nicht relevant

Am Ende sind das alles auch nur Schichten!

HAB ICH DIR GAR NICHTS BEIGEBERACHT, JESSE?!!

Wie begegnen wir dem Mythos?

Unterschiede verstehen

Geschichtsstunde!

Gemeinsamkeiten

  • Dependency Inversion
  • Dependency Rule: Code-Abhängigkeiten nur nach innen
  • Entkopplung über Interfaces
  • Struktur: Trennung von Fachlichkeit und Technik
    • Domain innen, Technik aussen

Cockburn, 2005

Hexagonal Architecture
(Ports & Adapter)

  • Kennt nur "innen" (Application) und "aussen" (alles Andere)
  • Strikte Verantwortlichkeiten der Bausteine:
    • Ports: fachlich motivierte Interfaces
    • Adapter: technische Anbindung an Umwelt
    • External Actor Systeme, Prozesse, Rollen, Benutzer, ...
    • Anbindung: Driven / Driving
→ Fokus: Interaktion von Application und Umwelt

Palermo, 2008

The Onion Architecture

  • macht Aussagen über Struktur “des Inneren”
  • Fordert Interfaces, aber
    • macht keine Aussagen über konkrete Bausteine
  • Kritikpunkte:
    • “Layeritis”: ggf. kein Benefit durch zusätzliche Schichten
    • DDD: Domain Services getrennt vom Model?

Martin, 2012

Clean Architecture

Konsolidierung ähnlicher Ansätze:
  • BCE (Jacobsen, 1992)
  • Ports & Adapters (Cockburn, 2000)
  • Onion Architecture (Palermo, 2008)
  • DCI (Coplien, Reenskaug, 2010)

Explizite Hinweise zur Umsetzung, z.B:
  • Anzahl der Schichten nicht fest vorgegeben(!)
  • Nur simple Datenstrukturen sollten Schichtengrenzen überschreiten
  • Austauschbarkeit von Schichten / Segmenten, wenn diese obsolete werden → Evolution

Wir alle, heute

Ok, ... und jetzt?

  • Hexagonal, Onion, Clean machen Unterschiedliche Aussagen bzgl:
    • Innerer Struktur
    • Striktheit der Schichten
    • Charakteristik von Bausteinen

→ Entscheidung für ein Pattern übernimmt diese Aussagen für die eigene Architektur !!!

Wie begegnen wir dem Mythos?

  • Tradeoffs bewusst behandeln, z.B.:
    • Benefit von Abstraktion durch weitere Schichten?
    • Ist “Schichten austauschen können” ein relevantes Qualitätsmerkmal?
  • Strukturierung der Domain ist wichtig
    • Alle 3 Pattern sind dahingehend agnostisch
  • Alternativen kennen, z.B. Vertical Slice Architecture

→ Kenne die Qualitätsziele deiner Architektur !!!