Note: This is part of my series on Domain Driven Design:
- Part 1: Introduction and Entities
- Part 2: Value Objects and Services
- Part 3: Repositories and Factories
- 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.