Domain Driven Design and NoSQL TLV

DevCon TLV | © 2014 triAGENS GmbH | 2014-06-05 1

Domain Driven Designand NoSQL

DevCon TLV2014-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


ProjectYAWS

(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 theposition in the

result list shoulddepend on the

net margin.

Why are there norecommendations

Checkout is notusable!

… but that isobvious!

Developers areincompetent!


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 togather functionality methodically

continous interaction

Product Backlog

Stories / Epics

etc.


DomainDrivenDesign


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

BrazilT. Gilliam

Rain DogsT. Waits

Aggregate

Wishlist Little, Big 25

J. Crowley

In BrugesM.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


RelationalDatabases


in Relational Databases you have(very special) Relations

not a relation relation

Foreign Key

relationalAlgebra


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


NoSQLDatabases


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], ..


Matchbetween

Domain Driven Designand

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-DBsare 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

[email protected]+49 170 8602158

triAGENS GmbHHohenstaufenalle 43-4550674 Köln

www.triagens.de

mailto:[email protected]


Kontext Projekt oder BereichTitel Domain Driven Design und NoSQLAblage 70_PraesentationenID TRI-MS-1406-001Verantwortlich martin Schönert / triagensLeser öffentlichSicherheitsein. öffentlichSchlüsselworteSoftwareentwicklung DDD Evans NoSQL Multi-Model

Schritt Bearbeiter geplant bis Fertigstellung KommentarFinale Version m.Schönert 2014-06-05 2014-06-05

Version Datum Bearbeiter KommentarV1.00 2014-06-05 m.Schönert Finale Version

Folie Kommentar- -

Dokumentinformationen

Metainformationen Historie

Bearbeitungsschritte Todos

Domain Driven Design and NoSQL TLV

Documents

Transcript of Domain Driven Design and NoSQL TLV