I’ve recently worked on a really interesting project based on RavenDB and NServiceBus, there will be a lot of time to deeply speak about it.
This argument should be treated at least in a 1h talk or far better in an open panel discussion…if someone is interested ping me, we can do that!
Document databases perfectly suites some DDD principles, such as the concept of aggregate; be aware that I’m not saying that relational databases does not suite, this post is not about relational versus document (I dislike the “no-sql” name).

Read on…questions

After the “document-db” experience I asked myself one single question: why do I need an ORM?
The short answer is: we tend to introduce an ORM to solve a problem that we have introduced.
So…if we do not introduce the first problem do we need an ORM anymore? basically yes, but now the question “moves” to: what an ORM should do for us?
The short answer is in the name: ORM –> map relational data to objects (period).


Abuse

ORM(s) per se are a wonderful thing, as with everything, problems come with the abuse of the wonders Smile…typically what I hear from the field is something like: “I want to get rid of all that SQL strings that pollute my code”…
…and? they end up using hql strings with NHibernate…what is the difference? why the hell you want to hide SQL code from your program and then you want to view the generated SQL using a profiler?
I suppose, well at least it is what generally happens to me, that when we face the design of the database we tend to forget which will be, at the application level, the usage of the data we are designing…we tend to follow design guidelines and design rules instead of saying “I need the data in that shape, period”…and then we masturbate that data with an ORM to shape the perfectly normalized data in the form we really want them…

Astute…isn’t it?

Listen to me: give it up! try once to go back to the origin, use SQL, use Stored Procedures, design your data as you need them not as the book told you to design them…once you re-learned the “story” do you own choice, there are ton of tools out there that follows the “keep it simple, Luke” pattern:
Conclusion(s)

I suppose that the human kind is basically stupid and tends to forget too easily the past…”they” gave us SQL, then someone invented the ORM (I’ll repeat myself: a wonder, really) and we forgot that the ORM is basically a way to get rid of the SQL it is not a “replacement”, then ORM guys start to over-engineer giving us lot’s of features on top of ORM(s)…features that, if you use an Object Model, can be really lifesavers such as Identity Map or Unit of Work but gave us also the vacuum cleaner that let us hide under the carpet bad data design decisions…and obviously we start to use all that cool features…producing tons of joins or select n+1 and looking at SQL, yeah old hated SLQ hidden under the carpet, in a profiler to understand what is going on…why the hell our application is so slow…
Give a try to document databases, not because they are better than relational ones (they are not, both have pros and cons) but because they force your mind to go back to the basics, they force you to understand some DDD principles (such as Aggregates and Bounded Contexts) and they let us see the light at the and of the tunnel giving us the opportunity to completely re-think our approach to the relational model.

.m