Relational-only databases are great fit for storing relational models, but are fairly problematic and limited when it comes to storing aggregates in DDD (domain-driven design) systems. On the other hand, NoSQL document-oriented databases are natural fit for storing and loading [DDD] aggregates. In this session you are going to learn: - Why relational-only databases are problematic and limited for storing aggregates and how document-oriented databases come into play. - Why PostgreSQL is the perfect database for storing, loading and querying DDD aggregates. - How Marten .NET library makes developers productive working with PostgreSQL's document features, leveraging the powerful JSONB data type, without losing any of your existing LINQ and SQL knowledge. - And finally, how to use the features of both worlds combined (relational and document oriented) in the same database server, in order to get maximum out of this data access approach. Overall, this approach helps dev teams be more productive and focus on designing good domain models, instead of fighting the impediment mismatch between the object model and the relational model, which comes from relational-only databases, with or without using an object-relational mapper. Ultimately, this approach opens the doors to polyglot persistence.

1. Document-oriented data access for
domain-driven .NET systems with
PostgreSQL & Marten
Bojan Veljanovski, CTO at HASELT
October, 2017 @ Macedonian .NET User Group
1

2. What we are going to talk about?
● Limitations in relational-only DBs for storing true domain
aggregates
● How document-oriented DBs come into play
● Marten as document DB for .NET with PostgreSQL
● SQL + NoSQL => best of both worlds
2

3. Setting context
● How I got interested in document-oriented DBs?
Why it makes so much sense?
● Why PostgreSQL?
Why not MongoDb, CouchDb, RavenDb?
What about SQL Server, MySQL?
● Who else uses this approach?
3

4. Sample domain model
4

5. DDD Aggregate
Cluster of domain objects that can be treated as a
single unit.
● Consists of
○ Aggregate Root (or Root Entity)
○ Entities
○ Value Objects
○ Services
○ Repositories 5

6. Basic characteristics of an Aggregate Root
● Global identity
● Ensures invariants within aggregate
● Guarantees consistency
● Can reference other ARs only by identity
● Cannot reference non ARs
● Transactional consistency
● Stored and loaded in DB as a whole. 6

7. Relational-only model
7

8. Sample domain model in code
Let’s see the sample codebase in Visual Studio.
8

9. Limitations when working with
domain models in relational-only DBs...
● Cannot store an array of values
○ Needs new table with 1-m relation
● ...an array of objects
○ Needs new table with 1-m relation
● …a nested object
○ Needs new table with 1-1 relation
● …an AR in a single table
○ AR is spanned across many tables, and needs joinsThese limitations often lead to...
9

10. These limitations often lead to...
● Complex O/R mapping code
● Sacrificing encapsulation for easier O/R mapping
● Leak of domain logic to upper layers
● Anemic domain models - only data, no behavior
● Dev teams focusing on data-relations instead of
system behavior
● Implicit “SELECT N+1” problems
● Unit tests full with mocks & stubs 10

11. Moving out of the relational-only mindset
From thinking in terms of relations and data
To thinking in terms of behavior and data
11

12. Document model
12

13. How document-oriented DBs come into play
● Single document per [whole] aggregate
● Can store complex object graphs
● Can store arrays, collections, nested objects
● No need for ORM
● No limitations for creating rich domain models
● Dev team focus is in on behavior and logic
● Models are easy to unit test
13

14. Introducing PostgreSQL
14

15. Introducing PostgreSQL
● Object-relational database
● ACID
● Transactional
● Highly Extendable
● Open Source
● Free
15

16. PostgreSQL NoSQL data types
● Key/Value store
○ hstore
● Document store
○ json and jsonb
● Spatial and Geographic objects
○ postgis 16

17. PostgreSQL as document store:
Creating table with JSONB column
17

18. Inserting documents
18

19. Querying documents (1)
19

20. Querying documents (2)
20

21. Indexing documents
Various indexes are supported. 21

22. Marten as Document DB for
.NET with PostgreSQL
22

23. Introducing Marten
● OSS .NET library that provides polyglot persistence
● Document store
● Event store
● Uses PostgreSQL’s powerful JSON support
● Initial pre-alpha release on 08.12.2015
● Current version 2.3.2
● Community chat: gitter.im/JasperFx/marten
23

24. Getting started
24

25. Persisting documents
25

26. How our data looks like? -> User
26

27. Loading document by Id
27

28. Querying documents with LINQ
28

29. Filtering in arrays
29

30. Paging and sorting
30

31. Querying with plain SQL through Dapper
(yes, querying NoSQL documents with plain-old SQL)
31

32. Adding Foreign Key to Order document
32

33. How our data looks like with FK? -> Order
33

34. Querying multiple documents
by using SQL JOIN
34

35. Other notable features in Marten as Document Db
● Foreign Keys
● Indexes
● Duplicate columns
● Batched queries
● Compiled queries
● Bulk insert
● Multitenancy
● Optimistic Concurrency 35

36. Closing
36

37. Summary
● Relational-only DBs limit the ability to craft good
domain models
● Document DBs are natural fit for DDD Aggregates
● SQL + NoSQL in Postgres = best of both worlds
in a single DB provider
● Marten helps .NET devs leverage PostgreSQL as
polyglot database
● Polyglot data access mindset - there is no single
approach
37

38. Resources
● Marten
○ https://jasperfx.github.io/marten
○ https://gitter.im/JasperFx/marten
● PostgreSQL JSON Functions and Operators
○ https://www.postgresql.org
● This presentation’s code samples
○ https://github.com/bojanv91/MartenPostgreSamples
● Other useful articles
○ https://martinfowler.com/bliki/AggregateOrientedDatabase.html
38