Phil Bernie Consulting

There’s a bit of buzz around Domain Driven Design at the moment and while I haven’t gone too deep with DDD, there are certainly some aspects which have challenged the way I’ve been approaching problems.

In the past I’ve used plenty of ORM tools which are heavily dependent on the database and this reliance often results in a domain model that directly represents the database table schema. This is often a quick and convenient method of creating a data layer and it works well for the most basic of CRUD applications, however when your applications begin to get complex, this method can be left sorely wanting.

What has interested me most about DDD is the concept of a Doman Context and modeling "objects" based around a specific context. In a recent project this has worked for me in two ways.

First I had a domain context that was based around reporting, where I had data coming from a number of different tables but had to be mapped to a single object. The situation was analogous to having a business that could accept orders online, in store or by mail and each different order was stored in a separate table. I then wanted to create a sales report that showed a summary of all sales in a common format. With ORM solutions I’ve used in the past, I would have 3 objects mapped to my different tables called OnlineOrder, MailOrder and StoreOrder. I would then have had to massage that data into a common ReportOrder object and bind it to my report.

With NHibernate I was able to create a mapping for each table and map them all to the single ReportOrder object. This allowed me to have a nice clear representation of my domain model that was clearly abstracted away from my database model.

The second situation I had was where I had a single table that I needed to be represented in multiple domain contexts. For example I had a Customers table which had one-to-many relationship with an Addresses table and an Orders table. In one context I wanted to update the Addresses and in another context I wanted to validate orders. If I was using an old school ORM, I’d have a Customer object with a collection of Addresses AND a collection of Orders. I’d have to make a choice as to whether or not I wanted to lazy or eager load each collection based on what I was doing with the parent object. With NHibernate I was able to just create two seperate objects that did exactly what was required by domain context. One Customer object had a child collection of addresses whilst a seperate one had a child collection of Orders. This example is greatly simplified but being able to create multiple objects based on specific contexts has meant I’ve been able to greatly simplify my domain model and reduce the complexity of my objects.

I haven’t done enough DDD to consider myself an expert or not, but combined with NHibernate I’ve definitely been given plenty to think about when it comes to modeling my domains.