Hexagonal-, Onion- und Clean-Architecture verstehen in unter 15 Minuten

Im Video stelle ich euch die Hexagonale Architektur, die Onion Architecture und die Clean Architecture vor. Diese Architekturen helfen, flexible und übersichtliche Systeme zu bauen und ermöglichen ein Vorgehen nach Domain Driven Design.
Zunächst werfen wir einen Blick auf die klassische Schichtenarchitektur. Danach werde ich die Konzepte erläutern und Unterschiede sowie Gemeinsamkeiten der verschiedenen Architekturen aufzeigen.
00:00 Einleitung
00:55 Schichtenarchitektur
01:35 Probleme der Schichtenarchitektur
02:41 Dependency Inversion Prinzip
05:15 Hexagonale Architektur
08:14 Domain Driven Design
08:46 Onion Architecture
10:06 Clean Architecture
11:07 Vergleich
12:27 Fazit
Artikel mit Folien zum Video:
www.predic8.de/hexagonal-onio...
Schulungen Online, in Bonn oder als Firmenseminar:
Intensivkurs Softwarearchitektur: Paradigmen, Technik und Praxis
www.predic8.de/softwarearchit...
Mich, Thomas Bayer findet ihr auf:

[@Garpsta]

Super Einfuehrung :) Ich habe letztens noch eine BA von der HHU gelesen, wo die Erfinder sich einig waren, dass die Modelle mehr oder weniger dasselbe in Gruen sind. Interessant finde ich da die Blogbeitraege von Jimmy Bogard ueber seine Erfahrung bzgl Onion-Architektur und der daraus resultierenden Vertical Slice Architektur. Ich hoffe die wurde fuer das naechste Video geteasert :)

[@thomas-bayer]

Richtig getippt 😉 Das nächste Mal geht es um die Vertical Slice Architecture.

[@volkerraum3494]

Sehr gute Übersicht... Alistair Cockburn wird allerdings ohne "ck" ausgesprochen = Alistair Co burn

[@marcom.]

Irgendwie ist es alles die gleiche Suppe. Mich irritieren eher die Versuche, für die eigentlich immer gleichen Prinzipien ständig neue Namen zu erfinden.
Erstmal: Es sind doch alles Schichten-Architekturen. Und natürlich gab es auch schon vor 25 Jahren Abstraktionen durch die Trennung von Interface und Implementierungen. Ok, wir hatten da noch keine DI-Frameworks, aber sowas wie Factories und Service-Provider.
Neue Begriffe wie "Ports" einzuführen und mit einer hexagonalen Architektur irgendeine Bedeutung auf die Zahl 6 zu legen, halte ich für unnötig und täuscht diffuse Neuerungen vor, wo gar keine sind.
Die Onion Architektur bleibt leider eher vage in diesem Video. Es bleibt z.B. unklar, wieso die Infrastruktur ganz außen ist, obwohl da offenbar sowohl externe Infrastruktur (z.B. eine REST-API) als auch interne (Persistenz-Schicht) dazu gehört. Für mich auf diesem Level nicht nachvollziehbar.
Dann kommt noch die Clean Architecture, um die Verwirrung komplett zu machen. Irgendwie ähnlich zur Zwiebel und der Bienenwabe, aber schon wieder andere Begriffe auf anderen Abstraktionsebenen. Wo würde man z.B. Controller und Use Cases in der Zwiebel finden? Oder wieso sind Presenters auf gleicher Ebene wie Controller?

[@thomas-bayer]

Hallo @marcom, danke für deinen ausführlichen Kommentar. Der Unterschied zur klassischen Schichtenarchitektur ist bei den drei Architekturen die Unabhängigkeit zur Infrastruktur mittels Dependency Inversion. Ansonsten sind alle drei gleich und unterscheiden sich wie du schreibst nur im Namen, den Bezeichnungen und in der Notation der Diagramme. Selbst die Anzahl der Schichten ist in allen drei Ansätzen variabel. Die Diagramme, die in den Beschreibungen der Architekturen verwendet werden, unterscheiden sich, aber das ist nur Darstellung. Einige sehen da Unterschiede oder Vorschläge zur Einteilung der Schichten.
Die Persistenz-Schicht gehört nicht zum Kern der Anwendung, zumindest nicht die Implementierung der Schicht. Intern werden nur die Schnittstellen z.B. für Repositories festgelegt (Hex: Port, Onion: Domain Services, Clean: Application Layer), die Implementierung z.B. KundenNoSQLRepository wird weiter außerhalb angesiedelt (Hex: Adapter, Onion: Infrastructure, Clean: Interface Adapters).
Controller findest du im Zwiebelbeispiel von Palermo ganz außen in der Infrastrukturschicht. Use Cases sind in der Zwiebel in der Domain Schicht. Dass selbst Palermo sich nicht festlegt, wo genau was angesiedelt ist („The first layer around the Domain Model is where we would find interfaces…“) trägt sicher zur Verwirrung bei.