das domain model persistente domänenmodelle mit jpa 2.0 und bean validation
TRANSCRIPT
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.