An introduction
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, called the Nimble Methodsm 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: 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.
By the way, Domain Driven Design is a key element of the
Nimble Methodsm, our unique
set of disciplines and practices that enables StoneHenge Partners
to promise, with confidence, to deliver every project on time, on
budget and on target.