Onion Model

Länder von Schleupen.CS besitzen eine Onion-Architektur, bei der der DDD-Layer in eine Ports & Adapter-Architektur eingebunden wird. Im Zentrum hierbei ist das Domänenmodell, das technikneutral als "reine" POCOs (= plain old csharp objects) implementiert wird. Jede weitere äußere Schale greift dabei nur auf die inneren Schalen zu, nicht aber umgekehrt. Der Applicaton Core beinhaltet die Usecase Controller (oder auch Application Services genannt), die als Orchestrator zwischen den anderen Bausteinen fungieren. Dort wo notwendig, werden zusätzliche Domain Service innerhalb des Domain-Layers definiert (etwas ungenau und nicht eingezeichnet am "Rand" des Domänenmodells). Domain Services bilden Domänenlogik ab und nutzen lediglich Aggregate und bilden "übergreifende", reine Domänenlogik ab.

Anmerkung: Im Gegensatz zu Domain Services sind Usecase Controller Vermittler, um die Schalen miteinander zu verknüpfen.

Der Application Core wird also möglichst technologieneutral implementiert und die technologischen Abhängigkeiten sind weiter außen im Schalenmodell zu finden. Damit ist es einfach möglich, Technik auszutauschen!

Dependency Inversion

Um der Regel des Zugriffs von außen nach innen gerecht zu werden, wird Dependency Inversion als eines der SOLID-Prinzipien angewendet. Dabei sollen High-Level-Klassen nicht von Low-Level-Klassen abhängig sein, sondern beide von Abstraktionen (z.B. Interfaces) um diese Richtungsabhängigkeit zu steuern.

Dabei sollen Interfaces nicht von Details abhängig sein, sondern Details von Interfaces. Um das zu erläutern, zeigt folgende Abbildung ausgehend von einer Schichtenarchitektur den Übergang zum Onion Model. Dabei besteht der eigentliche Trick darin, die Schnittstellen zu verschieben, wodurch sich die Abhängigkeitsbeziehung dreht. Dies zeigt die nachfolgende Abbildung.

Damit gelingt es schlussendlich, den Application Core unabhängig von Technik zu halten. Dies ist sehr sinnvoll, damit technologische Änderungen wie beispielsweise die Ablösung der Kommunikationstechnologie von WCF zu Web-APIs möglichst einfach durchzuführen sind.

Aber auch die Möglichkeit des Testens durch Unittests ist einfacher isoliert möglich. Hierzu benötigt man nur die innere Schale und die Abhängigkeiten in Form von Schnittstellen können einfach durch Verwendung von Test-Doublen (Mocks, Stubs, Spys etc.) implementiert werden. Die Isolation entsteht, wenn Klassen keine Abhängigkeiten von Implementierungen mehr enthalten – weder zur Laufzeit, noch zur Übersetzungszeit. Konkrete Abhängigkeiten werden so spät wie möglich aufgelöst, d.h. zur Laufzeit.

Projektstruktur

Die Abbildung des Onion Models auf die Projektstruktur ist intuitiv und der folgenden Abbildung zu entnehmen.