domain-driven design und hexagonale architektur
TRANSCRIPT
DOMAIN DRIVEN DESIGN&
HEXAGONALE ARCHITEKTURvon Torben Fojuth / @Final_guy
in BremenBaue seit 10 Jahren Web-AnwendungenSchwerpunkte: Architektur, Coding Dojo, Clean Code Devloper
Neuland, Büro für Informatik
TEIL 1: THESE“Die Kombination von DDD und Hexagonaler
Architektur bietet EntwicklInnen klareAntworten auf die zentrale Fragen ihres
alltäglichen Handwerks. ”
WAS IST PASSIERT?
TEIL 2: DOMAIN DRIVEN DESIGN
BEGRIFFE1. Ubiquitous Language2. Bounded Context3. Entity/Aggregate & Value Object
UBIQUITOUS LANGUAGE
ENTITYRepräsentiert ein identifizierbares "Ding"Kapselt GeschäftslogikHat einen Lebenszyklus / HistorieIst von der Datenhaltung abstrahiertGleichheit basiert auf ID
VALUE OBJECTRepräsentiert Eigenschaft (eines Entities)Kapselt GeschäftslogikBekannte Beispiele: Money/Price & QuantityUnveränderlich implementiertGleichheit basiert auf der Gleichheit aller Eigenschaften
AGGREGATESpezialform eines EntitiesIst Wurzel eines Objektbaumes
APPLICATION SERVICERepräsentiert einen UseCase der DomäneOrchestriert was zu tun ist
REPOSITORYBietet Zugriff auf EntitiesVerhält sich wie Collection
TEIL 3: HEXAGONALE ARCHITEKTUR
ZIELSETZUNG“Allow an application to equally be driven by
users, programs, automated test or batchscripts, and to be developed and tested in
isolation from its eventual run-time devicesand databases.”
Alistair Cockburn, 2005
URSPRUNG
S.O.L.I.D.Dependency Inversion Principle
DEPENDENCY INVERSION
HEXAGON
PAKETSTRUKTUR
TEIL 4: NUTZEN FÜR ENTWICKLER
WO ÄNDERE/ERSTELLE ICH EINEN USECASE?
WO ÄNDERE/ERSTELLE ICH GESCHÄFTSLOGIK?
WIE GREIFE ICH AUF EXTERNE SYSTEME ZU?
WO BEGINNT/ENDET EINE TRANSAKTION?
SIND MEINE ABHÄNGIGKEITEN KORREKT?
WO ERMÖGLICHE ICH ZUGRIFF AUF MEINSYSTEM?
BOUNDED CONTEXT ZU UBIQUITOUS LANGUAGE
HALDE
