Domain Driven Design and NoSQL TLV

DevCon TLV | © 2014 triAGENS GmbH | 2014-06-05 1
Domain Driven Design
and NoSQL
DevCon TLV
2014-06-05
martin Schönert (triAGENS)
TRI-MS-1406-001-V100-20140605

martin
 Studied mathematics and
investigated algebraic
structures with the computer
 Since then in IT in many roles:
 Programmer
 Project Manager
 Product Owner
 etc.
 These days primarily architect
 Consulting other companies
 For the ArangoDB database

Project
YAWS
(Yet Another Web Shop)

Wellcome to the Specification Workshop
 Product managers
talk about what they
expect from the Shop
Site
 ability to browse through
the shop
 powerful search
 with good products at
the top
 rather informal
 all participants are in
high spirits
 no disagreements
The Expert, 2014, Lauris Beinerts

and so the developers develop
 Object Oriented
 3-tier Architectur
 Model View Controller
 Modern Framework
 Responsive Design
 etc.

but at handover
of course the
position in the
result list should
depend on the
net margin.
Why are there no
recommendations
Checkout is not
usable!
… but that is
obvious!
Developers are
incompetent!

what developers think of the business side

but in fact it is a problem in the system
 functionality is not gathered
methodically
 „obvious“ functions are
missing
 no common language
 misunderstandings about the
details of the functions

Agile Development helps to
gather functionality methodically
 continous interaction
 Product Backlog
 Stories / Epics
 etc.

Domain
Driven
Design

was described by Eric Evans
 Approach to model complex
business oriented software
 centers around the business
logic
 towards this goal you model
the application domain

Ubiqous Language
 common language
 is used by ALL participants
 is used in ALL phases of the
project
 must be based on the
business logic

Entities
 have an identity
 two identities are different
even if they have the same
values for all attributes
 Examples
 Persons
 Shopping Cart
 Mutability

Value Objects
 have no identity of their own
 are only defined by their
attributes
 can be copied (without
changing the semantics)
 Examples:
 Product descriptions
 Immutable (at least from the
business logic view)

Aggregates
 Collection of entities and value
objects into one transactional
unit
 one entity defines the access
for the aggregate
 the controlled access allows to
maintain the invariants
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

Associations
 Relations between entities
and value objects
 can have properties
 are usually inmutable
knows
knows
works-for
knows
send-request
invited
works-for
shares-flat

Factories
 create complex aggregates,
entities and value objects
 correspond to patterns
 Factory
 Builder
 Prototype
 Example:
 Create an aggregate for a new
user with empty shopping cart and
wish list

Repository
 Stores entities and aggregates
 Persistence
 corresponds to the bottom layer in
a 3 tier architecture
 Methods for searching
 Example:
 Product Catalog

Relational
Databases

in Relational Databases you have
(very special) Relations
not a relation relation
Foreign Key
relational
Algebra

you have Normal Forms
 Marc Rettig
 Rules of Data Normalization
 orig. published 1989
 (still very useful)
 (how many normal forms are
there: 1NF, 2NF, 3NF, BCNF,
4NF, 5NF, EKNF, DKNF,
6NF, ...)

what normal form means ...
 our nice objects are taken apart and distributes the pieces over
many tables

and then you need Joins
 Instructions (Joins) to put the
objects back together again
when you read them
 (Yes - there are joins for other
purposes)

and then you need Transactions
 Rules (Transactions) so that
nothing gets lost when you
piece the object together
again
 (Yes – there are transactions
for other purposes)

in short: Database Developers speak their own
language

NoSQL
Databases

Recently there has been a development of many
non relational databases: NoSQL
 Conditions for DBs have
changed
 functional requirements
 many simple operations
 non functional requirements
 Volume
 Variety
 Velocity
 hardware
 RAM is cheap
 SSDs

NoSQL databases are generally classified in
four categories
Key-Value Stores Document Databases
Extended Column Stores Graph Databases

A new development are the Multi-Model
Databases
Multi-Model Databases

Key-Value Stores are the simplest data stores
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
 Map Keys to Values (dict)
 Access only via the Key
 Values are unstructured
 usually no ability to loop over the
kv-pairs
 e.g. shopping cart
 scales very well

Document Databases
 Documents are sets of attribute/value
pairs
 Attributes can be structured
 lists, subobjects
 Collections
 external representation usually in
JSON
 e.g. product catalog
{
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“
}

Graph Databases
 Vertices
 usually objects (documents)
 Edges
 connecting two vertices
 directed (from → to)
 with type („knows“, „likes“)
 additional attributes
 e.g. relations between products
 [successor-of], [accessory-for], ..

Match
between
Domain Driven Design
and
NoSQL Datenbanken

Entities
 Entity
 Identity
 Complex Structure
 Variance
 document
 every document has its own
identity
 ID or Key Attribut
 structured attributes
 Schemaless
 no EAV neccessary
DDD Document database

Value Objects
 Value Object
 Inmutability
 document
 or
 Subobject in another
document (Entity oder VO)
 must be implemented on the
application layer

Aggregate
 Aggregate
 Central Access
 document with direct
references to other document
 must be implemented on the
application layer

Associations
 Association
 type of the association
 further properties
 Access methods based on
the associations
 e.g. recommendations
 Edge between two
documents
 type attribut of the edge
 additional attributes
 Graph algorithms in the
database
 e.g. path search
DDD Graph database

Repositories
 Repository
 Searching in Repositories
 Collection
 Queries
 using appropriate Indices
DDD NoSQL databases

Summary

DDD and Multi-Model-NoSQL-DBs
are made for one another
 A common language used by all participants throughout the
project is critical for the success.
 Domain Driven Design is an approach that demands and supports
such a language.
 Development with relational databases requires a unique
language (and way of approaching modelling).
 Non-relational/NoSQL DBs are modern DBs that fit the changed
constrains of modern software development better.
 There is a direct match between the language of Domain Driven
Design and the concents of NoSQL DBs.
 Multi-Model Databases – that marry document- and graph-models
– give a complete match in a single database.

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-1406-001
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-06-05 2014-06-05
Version Datum Bearbeiter Kommentar
V1.00 2014-06-05 m.Schönert Finale Version
Folie Kommentar
- -
Dokumentinformationen
Metainformationen Historie
Bearbeitungsschritte Todos

Domain Driven Design and NoSQL TLV

More Related Content

What's hot

Similar to Domain Driven Design and NoSQL TLV

More from ArangoDB Database

Domain Driven Design and NoSQL TLV