Domain-driven Design

Die Ansätze aus Domain-driven Design (DDD) fordern und fördern die Betrachtung eines Systems primär mit Fokus auf das Domänenmodell und die Geschäftslogik statt auf technische Aspekte. Dabei ist ein zentrales Ziel, aus der Zusammenarbeit von Entwicklern und Domänenexperten eine fachlich passende Zerlegung und Umsetzung der Gesamtfunktionalität zu erreichen.

DDD bietet strategische Muster wie Ubiquitous Language, Bounded Context oder Context Map, um die Fachlichkeit zu erfassen, in einzelne Komponenten zu zerlegen und diese wiederum miteinander zu integrieren. Gleichzeitig definiert DDD auch eine Reihe von taktischen Mustern wie Aggregates, Repositories, Domain Services und (in aktuellen Auslegungen meist auch) Domain Events, welche sich als Bausteine für die konkrete Umsetzung der Fachlichkeit innerhalb einer Applikation eignen.

Onion Architecture

Unter dem Begriff “Onion Architecture” hat Jeffrey Palermo vor zehn Jahren in einer Blog-Serie einen Ansatz für eine Applikationsarchitektur beschrieben, welche ebenfalls die Fachlichkeit ins Zentrum stellt, sogar bildlich gesprochen: Die Onion Architecture besteht aus einer je nach Definition unterschiedlicher Anzahl konzentrischer Ringe, welche jeweils bestimmte Aspekte der Applikationsarchitektur beheimaten.

Übersicht Onion Architecture
Übersicht Onion Architecture

Typischerweise werden Ringe für das Domänenmodell, für die Domänen- bzw. Applikationsservices sowie für die Infrastruktur unterschieden. Code in äusseren Ringen darf dabei auf Code in inneren Ringen zugreifen, aber nicht umgekehrt. Die Abhängigkeiten zeigen daher immer von aussen nach innen. Im Zentrum der “Zwiebel” liegt das Domänenmodell mit der Kern-Geschäftslogik. Im Unterschied zu einer klassischen Layered Architecture basiert somit “alles” auf diesem Domänenmodell, und nicht auf der Persistenzschicht mit ihren meist fachlich “blutleeren” Entitäten.

Ein Ziel der Onion Architecture ist eine klare Trennung zwischen fachlichem Code und der Infrastruktur. Eine Argumentation dabei ist, dass die Geschäftslogik im Vergleich zu den sich ständig verändernen Infrastrukturtechnologien und -Frameworks deutlich stabiler und langlebiger ist und daher als das tragfähige Fundament für eine nachhaltige Zukunft des Systems dienen soll. Eine weitere - und im Kontext von DDD vielleicht relevantere - Argumentation ist, die Fachlichkeit ohne Vermischung mit technischen Aspekten wie Transaktionen, Persistenz, Authentisierung oder Remoting abzubilden. Ähnliche Ziele verfolgen auch die Hexagonal Architecture von Alistair Cockburn oder die Screaming Architecture von Uncle Bob.

Drei Gute Gründe …

Nach dieser kurzen Einführung in DDD und die Onion Architecture sehe ich nun mindestens folgende Gründe, weshalb sich der Ansatz der Onion Architecture besonders gut für die Umsetzung von Bounded Contexts nach DDD eignet:

Ausblick

Insbesondere die Abbildung von taktischen Mustern in der Onion Architecture lässt sich durch die Verwendung von Stereotypen sehr explizit und mit einer Reihe von zusätzlich positiven Nebeneffekten realisieren. Mehr dazu dann in einem zukünftigen Blog-Post.