DOMAIN DRIVEN DESIGN HEXAGONALE ARCHITEKTUR · TEIL 1: THESE “Die Kombination von DDD und...

Preview:

Citation preview

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. ”

WOHIN GEHÖRT DAS FEATURE?

BEISPIEL: MAXIMALE BESTELLSUMME?

TEIL 2: DOMAIN DRIVEN DESIGN

BEGRIFFE1. Ubiquitous Language2. Bounded Context3. Entity/Aggregate & Value Object

UBIQUITOUS LANGUAGE

EntityValueObject

RepositoryApplicationService

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

Recommended