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 Blogged 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 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 theDomain, 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 Evans 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.