Fassung A aus Lektion 4.10.2 hat gezeigt, was Microsofts Leitfaden über Schichten sagt: Die Geschäftslogik hängt am Datenzugriff, und wer sie prüfen will, öffnet eine Datenbank. Derselbe Leitfaden nennt auch das Mittel dagegen, das Dependency Inversion Principle. Wendet man es konsequent an, landet man bei einer Architektur, die über die Jahre mehrere Namen hatte. In dieser Lektion heißt sie so, wie die meisten Vorlagen für .NET sie heute nennen: Onion und Clean Architecture.

Sie bauen Fassung B der Wiedervorlage mit der Domäne in der Mitte, Anwendungsfällen als eigenem Projekt und der Infrastruktur außen. Dann kommt dieselbe Änderung wie in Fassung A, und Sie messen dasselbe. Einen Messpunkt nehmen Sie diesmal besonders genau: die Typen, die nur abbilden. Sie sind der Preis, den dieser Stil am sichtbarsten zahlt.

Die Domäne in der Mitte

Die Onion-Architektur (Jeffrey Palermo) zeichnet ein Programm als Zwiebel. In der Mitte liegt das Domänenmodell, um es herum Ringe für Domänendienste und Anwendungsdienste, ganz außen die Oberfläche, die Infrastruktur und die Tests. Eine Regel hält das Bild zusammen: Jeder Ring darf nur die Ringe weiter innen kennen. Was außen liegt, kennt die Mitte; die Mitte kennt nichts außerhalb von sich.

Microsofts Leitfaden „Common web application architectures“ (unter Weiterlesen) beschreibt dieselbe Zwiebel als Sicht auf Clean Architecture: Die Geschäftslogik und das Modell der Anwendung stehen in der Mitte, und statt dass die Geschäftslogik vom Datenzugriff abhängt, ist die Abhängigkeit umgedreht. Die Infrastruktur hängt vom Kern ab. Das gelingt, weil der Kern Schnittstellen definiert und die Infrastruktur sie umsetzt. Zwei Sätze aus dem Leitfaden sind für diese Lektion besonders wichtig:

  • Oberfläche und Infrastruktur hängen beide vom Kern ab, aber nicht notwendig voneinander.
  • Beim Kompilieren arbeitet die Oberfläche nur mit den Schnittstellen des Kerns. Zur Laufzeit braucht sie die Klassen der Infrastruktur trotzdem, und die Dependency Injection verbindet beides beim Start.

Der zweite Satz löst ein Rätsel, das Fassung A mit PrepareFollowUps nur umgangen hat: Wer setzt die Teile zusammen, wenn niemand alle kennen darf? Antwort: die Composition Root, Program.cs, und nur sie. Der Leitfaden erlaubt dafür ausdrücklich, dass das Projekt der Oberfläche auf das der Infrastruktur verweist, mit der Bitte, Typen daraus nur in der Composition Root zu benutzen.