Das Domain Model

Persistente Domänenmodelle mit JPA 2.0 und Bean Validation

History

Das Domain Model ist klassischerweise ein Artefakt aus der Analyse und nicht ein Artefakt aus der Programmierung. Dokumentation der Schlüssel-Konzepte und Fach-Vokabular

Mit der Objekt-Orientierten Programmierung und modernen Platformen kann ein Domain Model (mehr oder weniger) direkt in Code abgebildet werden.

PoEAA: Martin Fowler listed das Domain Model als Programmier-Pattern auf Kontrast zu Transaction Script und Table

Module

Das Pattern“An object model of the domain that incorporates both behavior and data.”

Anwendung von bewährten OO-Techniken für die Implementation der Geschäftslogik:

Kapselung, Vererbung, Polymorphie, Design Patterns ...

OO verspricht:• bessere Skalierung bei zunehmender Komplexität• bessere Erweiterbarkeit• bessere Wartbarkeit•weniger Redundanz

Technologie

Fokus auf «reine» objekt-orientierte Programmierung

Kontrast zu infrastruktur-lastigen und OO-feindlichen Technologien wie EJB2 oder JDBC-Resultsets

POJOs – Plain Old Java Objects Fowler et al, 2000 Keine Abhängigkeiten, keine Konventionen Freiheit im OO-Design

Architektur: Domain Layer

Zentralisierung und Lokalisierung von Business Logik (DRY)

Context independent Persistence Ignorance

Zwei typische Herausforderungen

Peristence-Ignorance Testbarkeit Wiederverwendbarkeit Freiheit im OO-Design

ORM mit JPA bietet einen Lösungsansatz

Zentralisierung der Validierungs-Logik Validierung auf verschiedenen Ebenen (UI, Business-Logik, DB)

Bean Validation bietet einen Lösungsansatz

Klassen + Metadaten

Klassen werden mit Metadaten angereichert

Metadaten sind verantwortlich für einen speziellen (infrastruktur) Concern

Metadaten werden zu Laufzeit von einer Runtime konsumiert

Kern-Logik bleibt entkoppelt von den Metadaten

Klassisch in XML Seit JDK 5 als annotations

First level language construct, weniger Artefakte

Aber: Abweichung von POJO

Domain Modeling is not about the Tool! POJOs -> Rückkehr zu klassischen Werten der

Objekt-Orientierten Programmierung

Domain Driven Design by Eric Evans

If everyone agrees that it's obviously correct: that the system has layers the one at the top is a website the one at the bottom is a database

...then you probably don´t have much of a domain!Note that adding an ORM layer does not magically create a domain!

- Keith Braithwaite

Anwendbarkeit des Domain Model Patterns

Der Einsatz des Domain Model Patterns macht vor allem Sinn für die Umsetzung von komplexer, erweiterbarer und wartbarer Geschäftslogik

Der Einsatz der Technologien JPA und BeanValidation kann auch ohne Umsetzung des Domain Model Patterns Sinn machen.