Anwendungsdomain

Anwendungsdomain

Der Begriff Domain ist in der Informatik vielfach überladen und braucht daher eine genaue Definition für den Verwendungskontext. Als Anwendungsdomain wird hier der fachlich zentrale Bereich der Applikation verstanden. Hier sind die Klassen des fachlichen Modells, die die Geschäftsregeln (business rules) und fachlichen Anwendungsfälle (use cases) abbilden.

Es gibt unterschiedliche Ansätze, wie das Klassenmodell der Anwendungsdomain am besten entwickelt und strukturiert wird. Weitgehend unbestritten ist das bereits 1992 von Ivar Jacobson publizierte Konzept, dass eine (Anwendungs-) Domäne am besten mit drei unterschiedlichen Kategorien von Klassen aufgebaut wird.

Das ECB-Konzept

Entity Klassen

Objekte dieser Klassen repräsentieren Informationen über Dinge, Konzepte, Personen, Rollen, die für die Domain relevant sind. Typischerweise werden diese Informationen in einer Datenbank abgelegt oder anderweitig persistent gespeichert. Entity Klassen besitzen keine für den Ablauf von Anwendungsfällen wichtigen Methoden. Über Constraints ihrer Beziehungen (Multiplizität, Optionalität) legen sie aber wichtige Regeln (business rules) fest.
Beispiel: Jeder Kunde der Bank muss mindestens ein Konto haben.

Controller Klassen

Objekte dieser Klassen steuern innere Abläfe in der Domain. Bei technischen Systemen übernehmen sie typischerweise die Ablaufsteuerung, Koordination und Überwachung der externen und internen Subsysteme. Bei Informationssystemen werden sie z.B. für die Koordination komplexer Anwendungsfälle mit mehreren beteiligten Akteuren oder für automatische interne Prozesse eingesetzt. Sie enthalten keine Geschäftsdaten. Daten werden nur persistiert, wenn dies zur Steuerung langlaufender Prozesse notwendig ist. In der Regel sind sie nicht direkt mit externen Akteuren verbunden, das übernehmen Boundary Objekte.
Beispiele: Immobilienkreditantrag bearbeiten, Kundenbonität überwachen.

Boundary Klassen

Objekte dieser Klassen repräsentieren eine Menge von Operationen, die die Domäne nach außen bereit stellt. In der Regel hat ein Objekt genau einen externen Nutzer, z.B. einen Akteur oder ein externes System. Boundary Objekte können an mehreren Anwendungsfällen beteiligt sein.
Beispiel: Alle für Kunden zugänglichen Methoden zur Kontoführung (einzahlen, abheben, überweisen usw.) werden über ein Boundary-Objekt bereitgestellt.

Weiterhin hat es sich als erfolgversprechend herausgestellt, bei der Entwicklung der Anwendungsdomäne möglichst präzise die Begriffe und Strukturen der Anwendungsexperten zu verwenden. Dies wird z.B. von Heinz Züllighoven und Carola Lilienthal in diesem Artikel betont. Auch die Tools&Materials Methode von Züllighoven betont diesen Aspekt. Im Domain Driven Design, das von Eric Evans geprägt wurde, spielt die Ubiquitous Language eine zentrale Rolle. Ein interessanter Artikel dazu stammt von Dan Haywood.

Für die Implementierung von ECB-Klassen in Java Enterprise Frameworks gibt es unterschiedliche Ansätze

Kategorie	JEE	Spring
Entity	Persistent Entity	Pojo + Repository Interface
Controller	Stateful Session Bean	Pojo: @Service
Boundary	Stateless oder Stateful Session Bean	Pojo: @Service Pojo: @Controller
Pojo = Plain Old Java Objekt, ein ganz normales Java Objekt @Service = Annotation definiert eine Spring Bean @Controller = Service, der vom Spring Servlet aufgerufen wird

Mehrere Domains in einer Anwendung

In der Regel gibt es mehrere fachliche Ebenen in einer Applikation, die nicht alle mit den Fachleuten des Anwendungsgebiets erarbeitet werden können und müssen. Beispielsweise können die Anwender die Anforderung stellen, dass bestimmte Dokumente nur vom Ersteller, seinem Vorgesetzten und der Revisionsabteilung gelesen werden dürfen. Sie können aber keine Hinweise geben, wie dies mit Access Control Lists realisiert werden soll, weil dies kein Bestandteil ihrer Arbeit ist. Es ist daher sinnvoll, eine Applikation in mehrere Domains zu gliedern. Dabei kann man Domains sowohl nach der Rolle als auch nach dem Inhalt klassifizieren:

Rolle: Client

Die Domain nutzt Services, die von einer oder mehreren anderen Domains bereitgestellt werden. Eine Domain, die von keiner anderen Domain genutzt wird, wird meist als die Anwendungsdomain bezeichnet. In der Anforderungsanalyse werden dadurch die Anforderungen des Client an den bereitstellenden Service festgestellt. Für die Implementierung bedeutet das, dass der Client die API des Service nutzt und dafür ggf. bestimmte Pattern implementieren muss.

Rolle: Service

Die Domain stellt Services zur Verfügung, die von anderen Domains im System genutzt werden. Prinzipiell können zwei Domains gegenseitig sowohl Client als auch Service sein. Die Client-Service-Verbindung kann als eine Bridge zwischen den Domains betrachtet werden, die eine lose Kopplung ermöglichen soll.

Inhalt: Fachlich

Der fachliche Inhalt und die Terminologie werden von den Anwendern bestimmt. Die Informatiker bilden dies auf die von den Frameworks bereitgestellten Implementierungsmechanismen ab. In unserer Beispielapplikation ist das agiles Vorgehen mit Scrum. Hier sind also Informatiker auch einmal die Fachexperten.

Inhalt: Technologisch

Diese Domains dienen in der Regel zur Einbindung externer technischer Geräte oder spezialisierter Programmkomponenten. Die Anwender spezifizieren funktionale Anforderungen und geben oft die Auswahl der Technologie vor. Die Informatiker bilden die Anforderungen auf die API der Technologie ab. Beispiel sind bestimmte UI Technologien (bei uns Vaadin), externe Geräte mit Programierschnittstelle oder andere unabhängig existierende Systeme.

Inhalt: Axiomatisch

Hier geht es um die Implementierung von Konzepten der Informatik. In Frameworks sind diese Domains in der Regel vorhanden. Beispiele sind Sicherheit, Zugriffskontrolle, Persistenz usw. Die Herausforderung für Softwareentwickler besteht oft darin, Konzepte und APIs hinreichend zu verstehen und auf die Anforderungen der Clients abzubilden.

Aufgabe

Identifizieren Sie die Domains der Beispielapplikation. Welche durch Spring bzw. Vaadin zur Verfügung gestellten Domains werden genutzt? Welche Domains werden selbst implementiert?