Domain Driven Design with MongoDB - Chris Hafey, On Point Medical Diagnostics

Slide 1

Slide 1 text

Domain Driven Design with MongoDB Chris Hafey [email protected] CTO, OnPoint Medical Diagnos@cs

Slide 2

Slide 2 text

Domain Driven Design Overview Challenges Interes/ng Pa1erns Persistent Wrapper Repository Service Pub Sub Queueing Blob Storage

Slide 3

Slide 3 text

The GOF book of Today

Slide 4

Slide 4 text

Communica/on Challenges? Business Folks Tech Folks Scalability Cloud NoSQL Stock Price Customers Cash ﬂow Sales HTML5

Slide 5

Slide 5 text

Ubiquitous Language Business Folks Tech Folks Domain Model

Slide 6

Slide 6 text

Ports And Adapters Architecture Service Side API Applica@on + Domain Mock MongoDB Adapter Adapter Adapter Adapter

Slide 7

Slide 7 text

Ports And Adapters Architecture Service Side API Applica@on + Domain Mock MongoDB Adapter Adapter Adapter Adapter

Slide 8

Slide 8 text

All problems in computer science can be solved by another level of indirec6on -‐ David Wheeler

Slide 9

Slide 9 text

Services En@@es Value Objects Repositories Factories Domain Building Blocks

Slide 10

Slide 10 text

Value Objects Have no iden@ty Usually immutable Can own child value objects Address Price Color GeoLoca@on

Slide 11

Slide 11 text

En@@es Have a unique iden@ﬁer Have behavior Own child value objects Order Line Bank Account Withdrawal Pa@ent Visit

Slide 12

Slide 12 text

Aggregates Order Bank Account Pa@ent Record Have a unique iden@ﬁer Have behavior Own child en@@es

Slide 13

Slide 13 text

Challenges Why are we doing ORM? Why is my database load so high? Where does behavior go?

Slide 14

Slide 14 text

Why are we doing ORM? Repositories RDBMS

Slide 15

Slide 15 text

RDBMS So we can report on the transac@onal data?

Slide 16

Slide 16 text

MongoDB FTW! Repositories Document Oriented Storage

Slide 17

Slide 17 text

And when you have to… Repositories RDBMS

Slide 18

Slide 18 text

Why is my database load so high?

Slide 19

Slide 19 text

Why is my database load so high? •  Domain Models tend to be normalized -‐> Denormaliza@on is the black art of RDBMS •  DBAs not involved in the domain model design •  Extra work required to interact with individual en@@es managed by aggregates Order Customer OrderLine1 Insert Order OrderLine2 OrderLine3 OrderLine4 OrderLine5 Insert OrderLine Insert OrderLine Insert OrderLine Insert OrderLine Insert OrderLine

Slide 20

Slide 20 text

MongoDB FTW! Insert Document Order Customer OrderLine1 OrderLine2 OrderLine3 OrderLine4 OrderLine5 •  MongoDB’s document orienta@on eliminates the need for denormaliza@on •  Complex object graphs s@ll result in a single read or write to the database

Slide 21

Slide 21 text

Where does the behavior go?

Slide 22

Slide 22 text

Value Objects None – They are immutable! En66es State modiﬁca@on logic Repositories CRUD, Simple Queries, Schema Versioning Services Complex behavior related to mul@ple en@@es or other systems Where does the behavior go?

Slide 23

Slide 23 text

Interes/ng Pa1erns

Slide 24

Slide 24 text

Persistent Wrapper Wrapper class for pure domain model aggregates -‐  Has the MongoDB ObjectId -‐  Deﬁnes the type -‐  Schema Version -‐  Created and Updated TimeStamps -‐  Created and Updated User Ids -‐  Aggregates the domain model en@ty

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Repository Responsibili@es: CRUD Simple Queries Schema Version Logic

Slide 27

Slide 27 text

MongoDBRepository +Create +Get +Update +Delete +FindAll IUserRepository +Create +Get +Update +FindAll UserRepository -‐FromUserV1 User +Login +Password +Name +LastLoginTimeStamp UserV1 +Login +Password +Name <> <> <> <> Repository

Slide 28

Slide 28 text

Repository Things to consider: 1:1:1 – domain model aggregate -‐> repository -‐> collec@on Create a base repository class using generics Create separate concrete classes for each schema version Use a reﬂec@on driven automapper Create a separate service to handle more complex opera@ons -‐ Keep repositories simple!

Slide 29

Slide 29 text

Service Domain Services: Complex opera@ons spanning mul@ple aggregates e.g. Algorithms, merge, split Infrastructure Services: Communicate with outside world via adapters e.g. Complex opera@ons spanning mul@ple repositories

Slide 30

Slide 30 text

Service Things to consider: Talk directly to MongoDB for complex transac@ons -‐ Queries spanning mul@ple collec@ons -‐ Modiﬁca@ons to mul@ple documents -‐ Map/reduce Leverage repositories when possible -‐ Keep repositories simple

Slide 31

Slide 31 text

Pub Sub Queueing

Slide 32

Slide 32 text

Pub Sub Queueing Things to consider: Implement Pop using FindAndModify for single consumer For mul@ple consumers, use documents as changelog entries -‐ Include a @mestamp in the document so each consumer can keep track of what it has seen Reuse repository func@onality Periodically purge old entries in batch Separate collec@ons for each queue

Slide 33

Slide 33 text

Blob Storage Responsibili@es: CRUD for binary large objects Things to consider: Use GridFS! Make Blobs immutable so they are idempotent -‐ Use internally generated id for filename -‐ Two phase write – local disk first, then GridFS Make GridFS filenames self describing -‐ Embed type on end of filename -‐ Embed encoding as extension (.gzip, .zip, etc) Use GridFS metadata to further describe blob Store GridFS filename as an ajribute of a domain model en@ty

Slide 34

Slide 34 text

Blob Storage ImageUpload <> <> MongoDbFileRepository <> IFileRepository <> 2) writeImage(filename) <> 3) create(filename) 5) GridFS.Upload 1) Generate unique filename Image +GridFSFilename

Slide 35

Slide 35 text

Ques@ons?