Domain Driven Design

I attended the one day QCon Tutorial on Domain Driven Design by Eric
Evans. It was jam packed with real-world tips on dealing with software
complexity.

Introduction

In 1990's we were aiming for reuse, productivity and flexibility by
using object oriented systems. Here we are in 2007 and we still find
it elusive to achieve these in projects.

Eric said that his book was the result of analyzing several successful
projects and identifying the common elements in them. Those elements
do not guarantee success. There will be failures. The critical
complexity of most software projects is in understanding the domain
itself.

Experimentation - Fail Cheaply

Learn to brainstorm. It is cheap to fail at this stage. Go beyond the
first idea. Suggest two mutually exclusive ideas. This is a technique
to break out of the box. It allows us to explore the system beyond its
boundary.

So, look broader. Once we get a big picture we can zoom into the
smaller system that we are considering and come up with a better
solutions. The first idea can be a simple one.

Another way to fail cheaply is to prototype. Remember that is a throw
away so that the developer is free to make mistakes and does not have
to worry about doing it "The Right Way".

Terminology

Domain

The subject area to which the user applies a program is the "domain"
of the software.

Model

A model is a system of abstractions that describes selected aspects of
a domain and can be used to solve problems related to that domain. It
serves a particular use. It is NOT as realistic as possible. He gave
an interesting example of this: NASA uses Newton's principles, not
Einstein's even though it is a known fact that Einstein model is more
accurate. So it is useful relative to specific domain scenarios.

Ubiquitous Language

A language structured around the domain model and used by all team
members to connect all the activities of the team with the software.

Context

The setting in which a word or statement appears that determines its
meaning.,

Dealing with Clients and Resolving Impediments to Software Delivery

Core Vs Generic

Have you ever had the experience where you sit with a client and you
come up with a huge list of features for the software you are going to
develop? The client knows how to prioritize but do they know what is
essential in the domain that will satisfy their mission statement or
unique selling proposition?

Ask them:

1. What distinguishes your business from others?
2. What is your mission statement?

Use the answer as the criteria to find the core domain of the system
from the laundry list of features.

Generic things would be something that we could re-use and purchase
from a third-party. It could be used by your competition too, but the
core domain separates you from the rest. It gives you some kind of
competitive edge over your competitors.

Conclusion:

This is a must attend tutorial. I felt 3 days would have been ideal.
There is still lot to learn about domain driven design from the book.