Object Relational Mapping can help Domain Driven Design

In the book Domain Driven Design, Eric Evans promotes something called a ubiquitous language. The idea behind a ubiquitous language is that you have a consistent terminology that is used everywhere. Both business and technical experts should find and use this terminology in their conversations, and the terminology should appear directly in the source code, the database schema and also any written documentation. I guess he's basically saying that the language of the domain should be present and consistent throughout the entire "problem and solution space". This means that we don't have to work hard to translate between mental models.

I like this idea. It seems to eliminate redundent and duplicated terminology therefore making things simpler and less ambiguous. If you think about it, the language directly represents the concepts of the problem, so it makes sense to nail it down and use it consistently.

I'm striving to adopt this approach. One of my first problems is that I've been a little bit slack in keeping my database schema in check with the my domain objects. ReSharper doesn't automagically refactor my table names when I rename classes, so getting ubiquitous with my language requires more discipline 8-) So far I've tended to put this kind of thing off for a "rainy day". This is a bad habbit because rainy days don't seem to happen in my job. To make matters worse, it's going to be really tedious looking through all the classes and all the tables and columns working out where the language used is "out of date" or inconsistent. Or is it?

Today I realised something that's going to help me. I'm currently using NHibernate to map between by domain objects and my database. It occurred to me that the mapping files make a great single place to check that the language used in the database and objects is consistent. I reckon I can put a few hours aside to scan through the mapping files making note of any columns and tables that are named incorrectly. I can then simaltaneously write database update scripts and tweak the mapping files so that the database schema is corrected. How's that for getting a little leverage out of those hbm.xml files? 8-)

I guess this idea might be obvious to some, but I think it *is* going to be a useful when it comes to checking that language truly is consistent across databas objects and domain classes.