Why do O/R Mappers seem to be the favored persistence approach for DDD users?

Question

Why aren't there many DDD stories that use newer nosql tools such as db4o and Cassandra for persistence.

In my view, the effort involved in O/R mapping seems too high for the returned value. Being able to report right off the database is the main advantage I can see for my projects.

On the other hand, db4o seems to almost be the Repository pattern and Cassandra's concept of Column Families and SuperColumns seems to be perfect for defining Aggregates and their value objects (the scalability would just be an added bonus). Yet, most of the online resources giving examples of DDD projects seem to always default to using [N]Hibernate.

I don't have enough time/resources to take big risks by trying these newer tools on my projects which makes me want to opt for a very well documented approach to persistence. Is it possible that O/R mapping remains the norm just because people are afraid to give up the oh so reliable SQL? Should I make the leap?

Answer 1

Relational databases are designed for a specific category of use cases, particularly in business applications. As such, they have certain capabilities that are valuable in these scenarios. Data retrieval is often accompanied by sophisticated search and analysis. If you use NoSql or object databases, you may be giving up some of these capabilities in favor of others, such as the handling of huge, distributed datasets, a task at which NoSQL databases typically excel.

In other words, you may need more capabilities than just data persistence, capabilities which relational databases already provide. Relational databases are a mature, well-known and predictable technology, with many experts having abundant expertise in them. All of these reasons are good reasons for continuing to choose relational databases over more "exotic" solutions.

Answer 2

From what I've seen, DDD is most common in long-lived, business-oriented code bases. That's an area where the SQL database mindset reigns almost unchallenged so far. Some factors that play into that:

• People writing long-lived code bases tend to like technologies that have been around a long time.
• Large, business-oriented projects often take place in large businesses, which are naturally conservative.
• If you are starting your project with any existing data, it's likely to be in an SQL database to start with, and existing code likely tied to that.
• Most business projects are not very performance-sensitive, at least not in the same way that purely technical or consumer-focused efforts are.

And I'm sure there are more.

If you can't afford the financial risks that come with trying novel tools, then you should probably stick with the known thing. Some of the alternative persistence approaches are fantastic, and can get you radically more performance depending on need. But they are all early in their lifecycles. Although SQL databases have a lot of limitations, at least those limitations are pretty well known, both by you and the developers who will inherit your code.