Verwendung von Common-Domain-Logikstrukturen bei .NET-Anwendungen

Jeder Entwickler, der Software entwickelt und implementiert, wünscht sich, dass alles auf Anhieb funktioniert. Nichts ist frustrierender, als eine Lösung verwerfen oder überarbeiten zu müssen, nachdem man sich für einen bestimmten Weg entschieden und schon richtig viel Zeit investiert hat, weil der gewählte Ansatz nicht an neue Anforderungen angepasst werden kann. Mit den richtigen Strukturen für die Darstellung der Domänenlogik kann der Frust vermieden werden.

Der Code für diese Strukturen und die Terminologie sind dem Buch „Patterns of Enterprise Application Architecture“ von Martin Fowler, Addison-Wesley, 2003, entnommen.

Drei Strukturen

Es gibt viele verschiedene Möglichkeiten zur Organisation der Domänenlogik in Komponenten, die Kalkulationen, Validierungen und andere Logiken enthalten, welche die Kernfunktionalität der Anwendung bestimmen. Fowler definiert drei Architektur-Strukturen – Transaktionsskript, Tabellenmodul und Domänenmodul (im Folgenden nach steigender Komplexität besprochen) –, die von Entwicklern zur Organisation der Domänenlogik verwendet werden.

Transaktionsskript

Diese Struktur umfasst das Erstellen von Methoden in einer oder mehreren Geschäftskomponenten (Klassen), die direkt auf die von der Anwendung benötigte Funktionalität abbilden. Wie der Name schon sagt, ist jede Transaktion wie z. B. die Bearbeitung einer Bestellung in ihr eigenes Skript eingebettet, das sich in einer Methode einer Geschäftskomponente befindet. Der Hauptteil der einzelnen Methoden führt dann die Logik aus, wobei oftmals eine Transaktion zu Beginn gestartet und am Ende abgeschlossen wird (daher der Name).

Diese Struktur kann durch die Verwendung mehrerer Transaktionen pro Komponente implementiert werden. Dies ist das am weitesten verbreitete Verfahren; es erfordert die Faktorierung der Transaktionen in Gruppen einer höheren Stufe, wobei anschließend für jede Gruppe eine Geschäftskomponente sowie für jede Transaktion eine öffentliche oder gemeinsam genutzte Methode erstellt werden muss. Zum Beispiel umfasst der Bestellprozess für ein Produkt bei einer Online-Shop-Anwendung mehrere Schritte und kann in eine PlaceOrder-Methode innerhalb der OrderProcessing-Komponente eingebettet werden (siehe Listing A).

Die zweite Möglichkeit der Implementierung dieser Struktur ist die Separierung jeder einzelnen Transaktion in ihre eigene Komponente. Durch dieses Verfahren wird jedes Transaktionsskript in seiner eigenen Klasse implementiert, die Implementierungs- oder Schnittstellenvererbung verwendet, um Polymorphismus zu ermöglichen (entsprechend der Befehlsstruktur der GoF). So können beispielsweise die Skripts PlaceOrder und SaveCustomer als Klassen implementiert werden, die über die IProcessing-Schnittstelle erben, wie in Abbildung A dargestellt.

Diese Struktur ist zwar oft die intuitivste, doch ist sie nicht so flexibel wie andere Verfahren und ermöglicht keine Code-Wiederverwendung. Der Vorteil dieses Ansatzes besteht darin, dass er vom Konzept her unkompliziert zu entwickeln ist, indem man sich die Aktionen ansieht, welche die Anwendung durchführen muss. Diese Struktur stellt somit die Anwendung als Abfolge von Transaktionen dar.