These last months I have been learning Domain Driven Design. It’s often shorted to DDD. I have had plans to start looking into DDD for a while, but other things have always gotten in the way. I’m working as a consultant and some months ago I was assigned to a new customer, and they wanted to use DDD in their new project. Lucky for me :-) Now I got the change to look into this DDD stuff and I must say that it will influence how I design my applications in the future.
I find this subject extremely exiting, so I have decided to write some posts about it. Some of the subjects I will cover is Ubiquitous language, Domain Model, Entities, Value objects, Services, Aggregates, Repositories, Factories, Bounded context to list some.
How to get started
I started out my DDD journey by reading some books:
Domain-Driven Design: Tackling Complexity in the Heart of Software. This book is written by Erik Evans. It’s considered the bible of DDD. I have heard people referring to it as “Lord of the rings” for developers because it uses so many references to references to references. You know; Legolas was the son of Thranduil, King of the Woodland Realm of Northern Mirkwood, son of … you get the picture?
I use this book more as a reference, and I haven’t read it from page to page, but I have read a book which is a summary of Evans book; Domain Driven Design Quickly. It’s a good book and only a bit over 100 pages. It’s free and can be downloaded from InfoQ.
The book to blame for me learning DDD is written by Jimmy Nilssons and is called Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. It’s a great book which is easy to read and he uses a lot of examples to explain the concepts in DDD. Nilsson uses TDD through the hole book to explain what DDD is. This makes it very easy from the reader to follow.
The last book I have looked into is a book written by Tim McCharty. It’s called .NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer). This book contains a lot of code. The code can be found at Codeplex. I got some hint on how to implement some of the patterns that DDD fronts from this book.
I you find videos and podcasts more easy to learn from, I can recommend listening to Alt.NET podcast show about DDD. Scott Hanselman also have a interview with Rob Conery where the topic is DDD. The last podcast I will recommend is one from Deep fried bytes. This is a conversation with David Laribee.
If you want more links, you should go to this site. This guy have gathered some links to different DDD sources. You can also check my delicious bookmarks for updates to links.
Ubiquitous language and domain model
The first thing that pops into my mind when someone ask me about DDD is the domain model. That’s kind of obvious because we are talking about Domain Driven Design. DDD recommends that you start out by creating a domain model before you focus on anything else. Many developers would start out by focusing on the database when they create a application. This is not recommended by DDD. The reason for this is that you want to capture the domain in a model that the business person can understand. I’m referring to business person and domain expert in this post and I’m actually talking about the same person. The business person and domain expert is often the same person or at least, the business person is the product owner and should understand the domain model. You should sit down with the domain expert and try to create a shared language; the ubiquitous language. The reason for this is that you want a language that the business person and the developer understands. By doing this you will avoid many misunderstandings. What we did when starting to figure out the domain for the customer, was to get the domain experts to write down important concepts from the business we where trying to capture. We focused on using the same terms. They didn’t, for example, use the term order, but they used sale, so we called it sale in our domain model although it looked more like an order to me. When we had talked about the terms and how the different parts of the application should fit together, we started to mold the domain. We also created some simple sketches of parts of the domain.
The nice thing with the domain model, from a developers perspective, is that the model is the code. You don’t try to model the domain with a strange notation or tool. The code is the model. The reason we can use the code as the model, is the ubiquitous language. You are capturing requirements in terms the domain experts understands. If the domain expert is a developer, this is even simpler.
I’ll try to keep these posts short and focus at one thing at a time, so I guess this is time to end this post. Next time I will explain what a entity and a value object is.