Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
DDD: There Is No Database

Do not try to bend the spoon; that's impossible. Instead only try to realize the truth: There is no spoon.
The Matrix

Again prompted by discussion on the DDD Yahoo list, this post is intended to explain what on the face of it is a pretty dumb assertion – there is no database in DDD!

I’m sure right at this point, jdn is reaching for his keyboard to point out that I am dangerously close to repeating The Tao of Domain Driven Design. Yes, I love my mystical analogies!

But if you think about this apparently stupid statement, in the context of Domain Driven Design, it has a subtle and important point – DDD is all about the domain, not about the database, and Persistence Ignorance (PI) is a very important aspect of DDD.

What is Persistence Ignorance and Why Does it Matter?

This relatively new principle says we should try and keep our code free of anything that refers to, relates to, or propagates, aspects of the mechanism we intend to use for persisting our data – traditionally the good old relational database.

Early versions of this were focused on the imaginary requirement that we should be able to change from SQL Server to Oracle with relatively little effort. Changing connection strings wasn’t good enough, so various frameworks and adapters appeared to try and make this happen. Frequently however, knowledge of not only what specific database would be used, but even the fact that the data would be stored in a database leaked into our objects.

With persistence ignorance, we try and eliminate all knowledge from our business objects of how, where, why or even if they will be stored somewhere.

This is a major step towards decoupling our real code and logic from infrastructure concerns like data access, it therefore benefits us hugely in terms of testing, maintenance and change.

Where Does Persistence Ignorance Appear in DDD?

Pretty much everything in DDD is designed around PI, the basic pattern that is used for accessing Entities and Value Objects (the core building blocks of DDD which I will cover in my next post) is the Repository.

I won’t cover Repository in detail at this point in the series, but the primary purpose of a Repository is to represent itself as a collection, albeit a collection with fairly specific and advanced querying. The Repository provides a simple and powerful mechanism for making your Domain totally unaware of the actual persistence framework you are using behind it.

As a Repository is a collection, anything that uses it is completely unaware of where the Entity or Value Object may or may not have been stored.

So Why “There Is No Database”?

Domain Driven Design states specifically, in the name, why – we are designing our applications from the point of view of the Domain, and the Domain is drawn from the Ubiquitous Language we negotiate with our Domain Experts.

If we were to start with a database the it would be Database Driven Design. If we were to consciously or subconsciously bring elements from the database into our Domain, then we would risk compromising our Domain model purely to support the persistence layer we had chosen.

In Conclusion

Start from the premise “there is no database”, try to evolve the UL, the Domain, and everything that entails, without concern to the database you may or may not use in the end.

Eric covers in his book points where you may need to compromise one side or other, and good reasons for doing so, but if you start from a pure point of view, at least you will be making informed and explicit decisions about your compromises.

Previously:

1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts

Reference:

InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)

Repositories
Entities
Value Objects

del.icio.us Tags: DDD,Domain Driven Design,Practices and Principles


Posted 02-12-2009 7:27 AM by Jak Charlton

[Advertisement]

Comments

Wookie wrote re: DDD: There Is No Database
on 02-12-2009 4:54 AM

One thing I couldn't grasp yet is what to do with entities that rely heavily on queries (filters etc) to implement business logic.

For instance if I have a WarehouseItem entity, and the customer explains to me something like "an item should be called 'in-stock' if it's either present in the local warehouse, or in any warehouse in a 10-mile radius". So this would become a couple of queries against some tables in my system, which will be ultimately fired up by a repository.

But if I understood correctly the knowledge of what constitues an in-stock item (this rule about 10 miles etc)  should reside in the entity, not the repository. So how does the "knowledge transfer" happen from the entity (who knows the rules) to the repository (that runs actual queries)? Do I need some sort of storage-agnostic query object?

Ken McCormack wrote re: DDD: There Is No Database
on 02-12-2009 6:05 AM

Good post Casey : )   This sounds somewhat analgous to the OOD principle: objects are about behavior, not data.  It's certainly also a fundamental principle in designing with UML.

I like the idea though - forget the data layer for a minute!!  "Imagine we have thrown away SQL Server for a day and bought a shiny new object database!"

Peter Morris wrote re: DDD: There Is No Database
on 02-12-2009 6:05 AM

"Eric covers in his book points where you may need to compromise one side or other, and good reasons for doing so, but if you start from a pure point of view"

Effectively this last part says "There is no database....until later".  

At some point you have to bind the model to a DB and sometimes you will need to make a compromise in the structure of either the DB or the model, occasionally the compromise will be in the model.

Sure you shouldn't think of the DB when you are creating the model with the customer, but you need to keep it in mind when you are implementing.

Jak Charlton wrote re: DDD: There Is No Database
on 02-12-2009 6:07 AM

@Wookie

If you have an WarehouseItem with a method like "IsInStock", then this method is relative to the Customer you are asking about - this sounds like a scenario for a Specification and Double DIspatch ... bottom of this reply...

Let me know if this doesn't help or confuses more ... I'll cover a lot of these things later on in the series

The below was written when I misread a line on your question ... I will leave it as it applies in other situations ...

Well in your example, the knowledge of this query either belongs in the Repository<WarehouseItem>, in a strongly named method like .GetItemsAvailableForLocalPurchaseFor(ICustomer customer) (the name being representative of the UL) ... or it belongs in a Specification, for example AvailableForLocalPurchaseSpecification (again the name representing the UL) with a constructor taking a Customer.

Both of these could probably be abstracted from the Customer, by passing in a location rather than a Customer directly - saving the Repository having to reference Customer at all.

Business rules around querying do not belong on Entities, though the ability to ask an Entity whether it matches the query/Specification may well do so

So, your "agnostic query object" could be a Specification, or a strong method on the Repository - I would favour the Repository approach, unless there were a large number and variation of these rules, when I would switch to Specification

In addition, is this logic that belongs on a Repository? Is it something that can be resolved via a query?  Or does this perhaps belong in a RoutingService or a MappingService ... again this could only really be derived from the UL.

Double dispatch is worth reading up on:

en.wikipedia.org/.../Double_dispatch

Jak Charlton wrote re: DDD: There Is No Database
on 02-12-2009 6:14 AM

@Ken

Indeed it is - DDD is nothing more than OOD done right. Behaviour is important, data is not.

And yes, you could decide to go with an OO database, or go as far as Greg Young has done and throw the database away entirely and keep it all in memory

@Peter

You keep saying "you have to bind the model to a DB" ...

Firstly, you don't have to at all, and even if you do, a RDBMS is very different to an object DB. If you carry persistence to your domain, you will carry constraints too.

And if you get your abstractions right - why should

your DB affect your domain in any way?

DDD is not about implementation, it is about design - hence Domain Driven DESIGN ... what sits behind the Repository doesn't matter a whole lot to DDD

Dew Drop - February 12, 2009 | Alvin Ashcraft's Morning Dew wrote Dew Drop - February 12, 2009 | Alvin Ashcraft's Morning Dew
on 02-12-2009 9:42 AM

Pingback from  Dew Drop - February 12, 2009 | Alvin Ashcraft's Morning Dew

DotNetShoutout wrote DDD: There Is No Database - Casey Charlton - Insane World
on 02-12-2009 9:48 AM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Wookie wrote re: DDD: There Is No Database
on 02-12-2009 10:53 AM

Thanks for taking the time Casey, it is clearer now :)

I thought repositories should be really dumb, only having methods like FindById and FindAll, but if it's OK to have smarter methods like GetItemsAvailableForLocalPurchase then I'm set. It makes sense, I define this in my interface then different implementations of the repository have the knowledge of how to translate this into an actual db query, remote call, whatever suits.

jdn wrote re: DDD: There Is No Database
on 02-12-2009 11:00 AM

No, I'm with you on this one.  As someone who is very familiar and practiced with Data-Driven Architecture, I really prefer starting with focusing on the model and worrying about the DB as far down the road as possible.  Unless you have the right sorts of considerations in mind, designing a system around a database model blows.

Jak Charlton wrote re: DDD: There Is No Database
on 02-12-2009 11:20 AM

@wookie

I would say the opposite - dumb Repositories are a bad idea ... (commonly implemented as a generic IRepository<T>)

Greg discusses here : codebetter.com/.../ddd-the-generic-repository.aspx

A rich Repository with real Domain meaning is by far the best option

Community Blogs wrote DDD : Command Query Separation as an Architectural Concept
on 02-12-2009 12:23 PM

There has been some confusion recently around a recent evolution of DDD, the idea of Command Query Separation

Reflective Perspective - Chris Alcock » The Morning Brew #286 wrote Reflective Perspective - Chris Alcock &raquo; The Morning Brew #286
on 02-13-2009 3:29 AM

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #286

Jérémie Chassaing wrote re: DDD: There Is No Database
on 02-13-2009 8:14 AM

I totally agree with this vision, there's no database. My design has become far more supple since I follow it, and it lead me to great breakthrough in my design.

I made a post about how to lazy load with persitence ignorance recently because it's often a point where Persistence ignorance is hard to achieve.

I could seem contradictory, but actually lazy load means in the context that the relation between entities / valueobjects is a bit loose.

www.thinkbeforecoding.com/.../Lazy-load-and-persistence-ignorance

@wookie, you should really consider concrete repository interfaces, they give a true insight of what your repository is intended to do.

You can read this post too on this subject :

www.thinkbeforecoding.com/.../Repositories-and-IQueryable-the-paging-case

Community Blogs wrote DDD: Entities and Value Objects
on 02-13-2009 2:24 PM

Finally, after 5 posts in the series, we get to the beginning point, the basis of all things… Entities

Casey Charlton - Insane World wrote DDD: Where is the Code? Another Brief Interlude
on 02-14-2009 12:28 PM

Right about now I can hear murmurs, &quot;I haven&#39;t seen any code yet&quot; That is because I view

Community Blogs wrote DDD: Where is the Code? Another Brief Interlude
on 02-14-2009 12:58 PM

Right about now I can hear murmurs, &quot;I haven&#39;t seen any code yet&quot; That is because I view

Daniel Teng wrote Weekly links #1
on 02-15-2009 5:01 AM

关于敏捷

FixingtheAgileEngineeringProblemblog.gdinwiddie.com/.../fixing-the-agile-en...

Casey Charlton - Insane World wrote DDD: Aggregates and Aggregate Roots
on 02-16-2009 9:51 AM

Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some

Community Blogs wrote DDD: Aggregates and Aggregate Roots
on 02-16-2009 10:30 AM

Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some

Casey Charlton - Insane World wrote DDD: Services
on 02-17-2009 4:38 PM

There can be no word more common in development, and no word used for such a multitude of different things

Community Blogs wrote DDD: Services
on 02-17-2009 4:44 PM

There can be no word more common in development, and no word used for such a multitude of different things

DDD: There Is No Database - Casey Charlton - Insane World « LockeVN’s PRESS on the wild wild web… wrote DDD: There Is No Database - Casey Charlton - Insane World &laquo; LockeVN&#8217;s PRESS on the wild wild web&#8230;
on 02-18-2009 3:05 AM

Pingback from  DDD: There Is No Database - Casey Charlton - Insane World &laquo; LockeVN&#8217;s PRESS on the wild wild web&#8230;

Casey Charlton - Insane World wrote DDD: What Kind of Applications Is It Suited To?
on 02-18-2009 2:20 PM

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited

Community Blogs wrote DDD: What Kind of Applications Is It Suited To?
on 02-18-2009 2:39 PM

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited

Casey Charlton - Insane World wrote DDD: The Repository Pattern
on 02-20-2009 3:30 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Community Blogs wrote DDD: The Repository Pattern
on 02-20-2009 4:11 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Casey Charlton - Insane World wrote DDD: Living In The Enterprise
on 02-21-2009 4:25 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Community Blogs wrote DDD: Living In The Enterprise
on 02-21-2009 4:48 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: The Repository Pattern
on 02-21-2009 10:41 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Insane World wrote DDD: Living In The Enterprise
on 02-21-2009 10:42 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

DDD Step By Step wrote DDD : Command Query Separation as an Architectural Concept
on 02-22-2009 3:33 PM

There has been some confusion recently around a recent evolution of DDD, the idea of Command Query Separation

DDD Step By Step wrote DDD: Entities and Value Objects
on 02-22-2009 3:34 PM

Finally, after 5 posts in the series, we get to the beginning point, the basis of all things… Entities

DDD Step By Step wrote DDD: Aggregates and Aggregate Roots
on 02-22-2009 3:34 PM

Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some

DDD Step By Step wrote DDD: Services
on 02-22-2009 3:35 PM

There can be no word more common in development, and no word used for such a multitude of different things

DDD Step By Step wrote DDD: What Kind of Applications Is It Suited To?
on 02-22-2009 3:36 PM

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited

DDD Step By Step wrote DDD: The Repository Pattern
on 02-22-2009 3:36 PM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

DDD Step By Step wrote DDD: Living In The Enterprise
on 02-22-2009 3:37 PM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: The Repository Pattern
on 02-26-2009 4:08 PM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Insane World wrote DDD: Living In The Enterprise
on 02-26-2009 4:08 PM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Billy McCafferty wrote re: DDD: There Is No Database
on 03-05-2009 1:38 AM

Brilliant title Casey...I firmly understand and agree with your point.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)