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

Bridge: Verbindung zwischen Client-Domain und Service-Domain
Bridge: Verbindung zwischen Client-Domain und Service-Domain
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

Domainchart mit 7 Domains der unterschiedlichen Kategorien
Beispiel für eine Domain Chart
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?

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.