Domain Driven Design und Nosql

Interactive Cologne | © 2014 triAGENS GmbH | 2014-05-25 1
Domain Driven Design
and NoSQL
Interactive Cologne
2014-04-25
martin Schönert (triAGENS)
TRI-MS-1405-003-V100-20140525

martin
 Mathematik studiert und
algebraische Strukturen mit
dem Computer untersucht
 seither in vielen Rollen in IT
 Programmierer
 Projektleiter
 Produktverantwortlicher
 etc.
 inzwischen vor allem Architekt
 beratend für andere Unternehmen
 für die ArangoDB Datenbank

Project
YAWS
(Yet Another Web Shop)

Willkommen zum Spezifikationsworkshop
 Produktmanager
erzählen was sie von
dem Shop erwarten
 Fähigkeit im Katalog zu
browser
 leistungsfähige Suche
 gute Produkte weit oben
 eher informell
 alle Beteiligten sind
guter Dinge
 keine Kontroversen
The Expert, 2014, Lauris Beinerts

und also entwickeln die Entwickler
 Objekt Orientiert
 3-tier Architektur
 Model View Controller
 Modernes Framework
 Responsive Design
 etc.

doch bei der Fertigstellung
Aber natürlich soll
das Ranking bei
der Suche auch
auf der Marge
basieren!
Wieso gibt es keine
Empfehlungen?
Der Checkout ist
so unbenutzbar!
Aber das ist doch
offensichtlich!
Die Entwickler sind
total unfähig!

was die Entwickler von der Fachseite halten

tatsächlich handelt es sich aber um ein
systemisches Problem
 Funktionalität wird nicht
methodisch erfasst
 „offensichtliche“ Funktionen
fehlen
 keine gemeinsame Sprache
 Missverständnisse über die
Funktionen

Agile Entwicklung hilft u.a.
Funktionalität methodisch zu erfassen
 Kontinuierliche Interaktion
 Product Backlog
 Stories / Epics
 etc.

Domain
Driven
Design

wurde von Eric Evans beschrieben
 Herangehensweise zur
Modellierung komplexer
businessorientierter Software
 stellt die Fachlichkeit in den
Mittelpunkt
 dazu wird die Anwendungs-
domäne modelliert (daher
Domain Driven Design)

Ubiquitäre Sprache
 einheitliche Sprache
 wird von allen Beteiligten
verwendet
 wird für alle Aspekte
verwendet
 muss auf der Fachlichkeit
basieren

Entitäten
 Haben eine Identität
 zwei Entitäten sind selbst
dann verschieden wenn sie in
allen Attributen gleich sind
 Beispiele
 Personen
 Einkaufskorb
 Mutabilität

Wertobjekte
 haben keine eigenständige
Identität
 sind nur über ihre Attribute
definiert
 können beliebig kopiert
werden
 Beispiele:
 Produktbeschreibung
 Unveränderbar (fachlich)

Aggregate
 Zusammenfassungen von
Entitäten und Wertobjekten zu
einer transaktionellen Einheit
 eine Entität bildet den Zugriff
zu dem Aggregat
 durch kontrollierten Zugriff
werden Invarianten bewahrt
Session
session-id
last-access
User
name
pw-hash
e-mail
Shopping-Cart
Ubiq
P.K. Dick
Brazil
T. Gilliam
Rain Dogs
T. Waits
Aggregate
Wishlist
Little, Big 25
J. Crowley
In Bruges
M.McDonagh

Assoziationen
 Beziehungen zwischen
Entitäten oder Wertobjekten
 können ebenfalls
Eigenschaften haben
 sind typischerweise
unveränderlich
knows
knows
works-for
knows
send-request
invited
works-for
shares-flat

Fabriken
 Erzeugen komplexe Entitäten,
Wertobjekte und insbesondere
Aggregate
 korrespondieren zu den
entsprechenden Patterns
 Fabrik
 Erbauer
 Prototype
 Beispiel:
 Erzeugung eines Aggregats für
einen neuen Benutzers mit
(leeren) Einkaufswagen und
Wunschliste

Repository
 Speichern von Entitäten und
Aggregaten
 Persistenz
 modelliert die entsprechende
Schicht in einer 3-Schichten
Architektur
 Methoden zur Suche
 Beispiel:
 Produktkatalog

Relationale
Datenbanken

in relationalen Datenbanken
gibt es (ganz besondere) Relationen
keine Relation Relation
Foreign Key
relationale
Algebra

gibt es Normalformen
 Marc Rettig
 Rules of Data Normalization
 orig. published 1989
 (und immer noch nützlich)
 (es ist nicht ganz klar wie viele
Normalformen es gibt: 1NF,
2NF, 3NF, BCNF, 4NF, 5NF,
EKNF, DKNF, 6NF, ...)

was Normalform u.a. bedeutet
 unsere schönen Objekte werden
in viele kleine Teile zerlegt und auf viele Tabellen verteilt

und also gibt es Joins
 Anleitungen (Joins) um die
Objekte beim Lesen wieder
zusammen zu setzen
 (Ja - es gibt auch noch aus
anderen Gründen Joins)

und also gibt es Transaktionen
 Vorfahrtsregeln (Transactions)
damit beim Zusammensetzen
keine Teile der Objekte
verloren gehen
 (Ja – es gibt auch noch aus
anderen Gründen
Transaktionen)

kurz: Datenbankentwickler
sprechen eine eigene ganz Sprache

NoSQL
Datenbanken

Inzwischen gibt es andere nicht-relationale
Datenbanken: NoSQL
 Bedingungen für DBs haben
sich geändert:
 Funktionelle Anforderungen
 viele einfache Operationen
 Nicht funktionelle Anf.
 Volume
 Variety
 Velocity
 Hardware
 RAM is cheap
 SSDs

NoSQL Datenbanken werden häufig in vier
Klassen (Models) eingeteilt:
Key-Value Stores Document Databases
Extended Column Stores Graph Databases

Daneben gibt es inzwischen einige sogenannte
Multi-Model Datenbanken
Multi-Model Databases

Key-Value Stores sind die einfachste Datenbank
Key ValueKey Value
Key Value2 { name: „paavo“ }
Key Value3 { first: „emil“ }
Key Value„runners“ { ids: [ 1, 2, 3, 5 ] }
Key Value5 { name:„haile“,act:1 }
Key Value1 { first: „paul“ }
Key Value„last“ 5
 Bilden Schlüssel auf Werte ab
(wie dict)
 Zugriff geht nur über den
Schlüssel
 Werte sind (für den KV-Store)
unstrukturiert
 häufig keine Möglichkeit über die
Paare zu laufen
 falls doch ist keine Reihenfolge
definiert
 z.B. Einkaufswage

Dokumentendatenbanken
 Dokumente sind Mengen von
Attribut/Werte Paaren
 Strukturierte Attribute
 Listen, Teilobjekte
 Collections
 Sammlungen von Dokumenten
 Externe Repräsentation meist in JSON
 Manchmal interne Speicherung
ebenfalls in JSON / BSON
 z.B. Produktkatalog
{
FirstName:"Jonathan",
Address:"15 Wanamassa Road",
Children:[
{Name:"Michael",Age:10},
{Name:"Jennifer", Age:8},
{Name:"Samantha", Age:5},
{Name:"Elena", Age:2}
],
Job: “Tennis Trainer“
}

Graphendatenbanken
 Knoten (Vertices)
 meistens Objekte (wie in
Dokumentendatenbanken)
 Kanten (Edges)
 verbinden zwei Objekte
 gerichtet (von → nach)
 mit Typ („knows“, „likes“)
 weiterer Information
 z.B. Beziehungen zwischen Produkten
 [Nachfolger-von], [Zubehör-für], ..

Korrespondenz
zwischen
Domain Driven Design
und
NoSQL Datenbanken

Entitäten
 Entität
 Identität
 komplexe Struktur
 Unterschiedlichkeit
 Dokument
 jedes Dokument hat eine
eigene Identität
 ID oder Key Attribut
 strukturierte Attribute
 Schemafreiheit
 kein EAV nötig
DDD Dokumentendatenbank

Wertobjekte
 Wertobjekt
 Unveränderbarkeit
 Dokument
 oder
 Subobjekt in einem anderem
Dokument (Entität oder WO)
 muss programmatisch
sichergestellt werden

Aggregate
 Aggregat
 Zentraler Zugriff
 Dokument mit direktem
Verweis auf andere
Dokumente
 muss programmatisch
sichergestellt werden

Assoziationen
 Assoziation
 Typ der Assoziation
 weitere Eigenschaften
 Zugriffsmethoden an Hand der
Assoziationen
 z.B. Empfehlungen
 Kante zwischen zwei
Dokumenten
 Typattribut der Kante
 weitere Attribute
 Graphalgorithmen in der
Datenbank
 z.B. zur Pfadsuche
DDD Graphendatenbank

Repositories
 Repository
 Suchen in Repositories
 Collection
 Queries
 mit entsprechenden Indizes
DDD NoSQL Datenbanken

Fazit

DDD und Multi-Model-NoSQL-DBs gehören
zusammen
 Für den Erfolg von Softwareprojekten ist u.a. eine gemeinsame
Sprache die von allen Beteiligten durchgängig benutzt wird wichtig
 Domain Driven Design ist eine Herangehensweise die eine solche
fordert und fördert
 Entwicklung mit relationalen DBs erfordert eine ganz eigene
Sprache (und Denkweise)
 Nicht-relationale/NoSQL DBs sind moderne DBs die besser zu den
geänderten Bedingungen moderner Softwareentwicklung passen
 Zwischen der einheitlichen Sprache von Domain Driven Design und
den Konzepten von NoSQL DBs existiert eine direkt Korrespondenz
 Eine vollständige Korrespondenz ist nur mit Multi-Model-DBs
gegeben die Dokumenten- und Graphendatenbanken vereinigen

triAGENS
Die triAGENS GmbH ist ein Dienstleister im
Bereich komplexer Informationssysteme und
webbasierter Business-Lösungen, mit hohen
Anforderungen an Performance, Skalierbarkeit
und Sicherheit.
triAGENS entwickelt High-Performance-
Datenbanken auf Basis optimierter
NoSQL-Datenbanktechnologien, die u.a. bei
der Deutschen Post zum Einsatz kommen.
The triAGENS GmbH is a service company in
the area of complex IT Systems and web based
business solutions with high requirements on
performance, scalability and security.
triAGENS supplies high performance databases
based on NoSQL database technology, which
are utilized for example by Deutsche Post.
martin Schönert
Geschäftsführer / executive director
m.schoenert@triagens.de
+49 170 8602158
triAGENS GmbH
Hohenstaufenalle 43-45
50674 Köln
www.triagens.de

Kontext Projekt oder Bereich
Titel Domain Driven Design und NoSQL
Ablage 70_Praesentationen
ID TRI-MS-1405-003
Verantwortlich martin Schönert / triagens
Leser öffentlich
Sicherheitsein. öffentlich
SchlüsselworteSoftwareentwicklung DDD Evans NoSQL Multi-Model
Schritt Bearbeiter geplant bis Fertigstellung Kommentar
Finale Version m.Schönert 2014-05-24 2014-05-24
Version Datum Bearbeiter Kommentar
V1.00 2014-05-24 m.Schönert Finale Version
Folie Kommentar
- -
Dokumentinformationen
Metainformationen Historie
Bearbeitungsschritte Todos

Domain Driven Design und Nosql

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Domain Driven Design und Nosql

Similar to Domain Driven Design und Nosql (20)

More from ArangoDB Database

More from ArangoDB Database (20)

Domain Driven Design und Nosql