Persistente Domänenmodelle mit JPA 2.0 und Bean Validation Das Domain Model Persistente Domänenmodelle mit JPA 2.0 und Bean Validation 1

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 UML!

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 Wiederverwendb

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.