Domain Driven Design Part 1: Introduction and Entities

Note: This is part of my series on Domain Driven Design:

  1. Part 1: Introduction and Entities
  2. Part 2: Value Objects and Services
  3. Part 3: Repositories and Factories
  4. Using Domain Driven Design with a Three Tiered Architecture

At StoneHenge Partners, we’ve realized that the best way to ensure the success of software development projects is to keep the focus on the users and their experience at all times. Too many times, once you get into the code, your focus shifts to the underlying technologies and the back end systems and you completely forget about those users that you are developing for.

There are several aspects of our software development methodology that allow us to keep this focus. We always have a User Experience Architect assigned to the project who’s only focus is the interaction of the user and making sure that the end project will satisfy their needs. We size, scope, and track projects user Function Point Analysis where you are solely focused on end user identifiable transactions and files. We do iterative development so that the end users sees progress on the application as soon as possible and can submit feedback. But, another aspect of our methodology that allows us to stay focused on the users is Domain Driven Design.

In Domain Driven Design, you start your application architecture by defining the ubiquitous domain language. You map out the domain objects as the user would see them. I worked for a number of years in the car rental industry, so I’ll use some examples from there to flesh these ideas out.

On a car rental website you have a collection of rates. Each rate has a car, location, pickup date, and return date associated with it. So, in our domain language we would map out what a Rate is. We’d follow this up by defining a Car and a Location. These are three Entities. What attributes come to a users mind when they think of these entities? What operations can be performed upon them?

When a user has chosen a Rate, they will book it. So, an operation on the Rate entity may be Book(). The result of a user booking a Rate would be a Reservation. So, this is another entity for our model. What attributes are associated with a Reservation? What operations?

Once you have walked completely through this process, you end up with your Domain completely mapped out. This is your ubiquitous language that will be used to describe everything that happens in the application.

The difference with Domain Driven Design is that these domain objects that are defined, these entities, feed directly into the code that is written. So, we have defined an entity called a Rate. We therefore have a class called a Rate. This has the properties of Car, Location, pickup date, and return date that we discussed. This also has a method called Book that returns a Reservation. At this level of the application code we are not thinking at all about how the data is going to be stored or communicated to the back end applications. We are thinking completely about the domain objects that the user would identify and understand.

So, there are five main patterns used in Domain Driven Design. These are Entities, Value Objects, Repositories, Services, and Factories. I have briefly discussed Entities in this post. Part 2 will continue with a discussion of Value Objects and the difference between these and Entities.

10 thoughts on “Domain Driven Design Part 1: Introduction and Entities

  1. Matt,

    This is a great post. I like how you simplified the domain driven design concepts with real life examples.

    I tried to use DDD concepts with ADO.NET EF before couple of months. With the first release of EF they don’t have built in support for POCO objects. So I had to build the domain model inside the data layer using partial classes.

    How do you see DDD interms of a three tier architecture? Which layers would the value Objects, Entities and Services belong to, assuming we are using some kind of ORM tool.


  2. Great question! We do use DDD for with three tiered architecture. The key is with the Repositories and Factories which I will discuss in the third post.

    Let’s take for instance a website that consists of a web front end, a middle tier, and a database. The customer comes to the website and saves an order. The web front end will create the Order entity and populate it with the information submitted by the user. It will then call the OrderFactory to determine what Repository to use to save the Order. In the config file, it is specified that MiddleTierRepository should be used to implement IOrderRepository. So, the Factory returns the MiddleTierRepository and the web front end calls SaveOrder on it. This Repository calls a web method in the middle tier called SaveOrder.

    The middle tier then receives the Order. It performs an type of validation upon it and decides to save it. It calls the same OrderFactory used above, but in its config file it is specified that SqlServerOrderRepository should be used in this instance to save the Order. So, the Factory returns the SqlServerOrderRepository, which also implements IOrderRepository, and calls SaveOrder on it to save it to the database.

    We do use an ORM tool in this environment. We use nHibernate. So, in the situation above, we would use NHibernateOrderRepository instead of SqlSeverOrderRepository for the middle tier to save the order to the database.

    Does that make sense? Using this in a 3 tiered environment is such a practical topic, I think I’ll devote the fourth post in this series to it.

  3. Matt,

    Thanks for the explanation on the three tier archicteture.
    So if I understood you right, you have more a 2 tier architecture right, because I don’t really count the database itself as a tier. So does your middle tier layer have both the domain model (value objects, entity objects and object services) and also your data access logic (like the SQLOrderRepository class) you mentioned?

    I was trying to take out the domain model to be a separate tier by itself. But when using ORM tools like Entity framework, the entities are really indirectly tied to a specific implemenatio(that ORM tool) and are not totally persistent ignorant.

    In the past the three tier architecture I was used to look like below. Presenation Layer ==> Business Layer ==> Data Access Layer and there will be another Domain layer which is basically just a DTO (only data and minimum behaviour) which can be referenced from any of the layers and just used for passing data around. But in domain driven design the DTOs are considered evil, except for those value objects which don’t need any state.

    So how did you tie all this concept in your architecture? If possible if you can share a diagram, it will be more descriptive.


  4. Hmm Matt, I didn’t know that database gets counted as the third tier. I was always thinking of the third tier as my data access layer.

    I researched a bit trying to find image that best represents what I want to said in a nice way and I found one.

    My question was in this kinda of multi-tier architecture, for the app I was building using Entity Framework, since the Entities live inside the data access layer where I have the ORM mapper, I don’t have a way to map between those entities and the separate domain model without big pain.

    So then I just decided to go with a two tier architecture (or three tier depending on if we count database as the third tier) where I only have a presenation and data access layer. The domain models still live in the data access layer, just separated by namespaces. The way I built business rules on those entities was by using partial classes.

    To summarize, I want to be able to separate domain model but I couldn’t without the support for persistent ignorant ORM tool. I don’t know may be it is easy with NHibernate but I couldn’t do it with ADO.NET EF.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s