Introduction to DDD for the implementation oriented

Regular readers of gridshore know that Allard and I have attended a training on DDD (Domain Driven Design) and that we have started a user group for DDD in the Netherlands. Allard is using DDD for a project @ JTeam and he is starting to use it for a second project at JTeam as well. I am starting to use it on a few new initiatives and I am refactoring my old backoffice application to make it ready for a new version based on the DDD principles.

A lot of activity in the DDD area, and a lot of discussions with colleagues and other interested people about DDD. The biggest question is of course WHY?. There is not a very simple answer to this question. Ok, maybe one: Why not?. But that is to easy and not very convincing. A lot of arguments against DDD are coming from people talking about implementation problems. This blog post is focussing on those people. Not that others should not read it, but I am writing this post with those people in my mind.

When we were explaining DDD to developers we often heard: Nothing different than what I am doing now, only other methods names. We than tried to convince them from a technical perspective only. Of course this is very hard. Especially because your trying to compare apples with pears. Design is not implementation. People having a hard time giving DDD a place are often not doing design at all. They call thinking about technical problems design. This not the same design as the third D in DDD.

So, as an implementer, what should you know about DDD. Well first thing you should learn is that you need a domain expert to talk to. The second thing you must learn is to create a ubiquitous language with the complete team. The third thing to learn is how to combine the knowledge from a domain expert and some technical requirements and describe this using the mentioned ubiquitous language.

Domain Driven Design is about helping you achieve this. DDD presents some basic principles that help you to create better applications. Applications that you can explain to all members of the team and to the domain expert using the ubiquitous language.

This post introduces some basic things that I picked up from the training by Eric Evans. I do want to stress that reading about DDD is not a replacement for the actual training. The training in itself is no replacement for doing actual projects using DDD.

I am already doing domain driven design

We are doing domain driven design for all our projects. Look this is our domain model for a project. Hmm, nice diagram. Well that is not completely what DDD is about. What does this diagram mean? Ahh, it is a graphical representation of the relationships between some of the most important entities and value objects of your model. But how did you get to this diagram? Did you talk to your domain expert? Does he understand it? Does it somehow reflect what he is thinking about when he is talking about his domain? Are all these terms known in the ubiquitous language? Are all project members talking about them in a consistent way?

DDD is not about creating a nice diagram. If diagrams help to understand the domain, it is wise to create them. Very often the creation of the diagram is helping to understand the domain. Usually developers and domain experts understand these kind of diagrams. But please do not call this diagram the model. The idea about DDD is to create a model using a ubiquitous language. To get better insights into the model, diagrams can surely help.

Of course I talk to the client

A very big part about DDD is talking to the domain expert. You must learn how to get information from a domain expert. Learn about the domain. When talking to people representing the client, make sure you are talking to a domain expert.

A few tips when interacting with the domain expert:

• When talking to the domain expert, make it a conversation. You should have mutual interest in having these talks.
• Share your own ideas around the model.
• Use multiple different ideas to get the discussion going.
• Bad ideas are good, they teach you a lot about what it is not.
• Use bad examples to see if you understand the domain expert and if he is still with you.
• Use scenarios to talk about the domain and the model. Also use realistic values, that way the domain expert knows better what you are talking about and you get a better feeling with your domain.
• Don’t think you need to talk to the domain expert once, make sure he is available to you the complete project.

Here is my Model

Central to domain driven design is the model. We all have an idea what a model is. To me the context for the model is very important. Do not make a model as realistic as possible. The model is a simplification of the domain. You leave out everything that is not needed for your specific need.

The model must be intuitive to users and simple to learn. In order to find the right model you should try to apply different scenarios to the model. If the domain expert does not understand the model, cannot talk about scenarios with respect to the model, the model is wrong. If the model is wrong, your code is wrong. If the code is wrong, I guess you understand what that means.

Context Map

I real eye opener to me during the training from Eric Evans was the context map. If you have read the book from eric, you can find it in his book. There is a small summary of the terms discussed online.

If your complete system becomes bigger and you need integrations with other systems, it is a very good time for a Context Map. The complete solution might exist from different contexts. Each context is created by different teams and often by different companies. With a context map, you plot these context and focus on their relationships. The type of relationship between two different contexts has it’s influence on the domain model.

An example:
A small company A uses a component from company B for plotting points of interest on a map. Now company A needs a feature to add extra characteristics to points of interest on the Map. Company B has no interest for these additional properties and do not change the model. This is a good example of a customer-supplier relationship. Does company A use the model of company B for it’s points of interest map? Or does company A create an adapter for all communication to company B and do data transformation. That way there is not dependency on the model of company B. Eric calls the first scenario a Conformist and the second an Anti corruption layer. The anti corruption layer is expensive at the start, but gives a lot of flexibility.

Eric discussed other relationships as well, things like: Shared Kernel, Separate ways, Open host and published language. These concepts are not new, but now they have a name. Plotting them on a context map and making them explicit in your ubiquitous language helps you when making choices in your model.

DDD is hard to implement

Depending on who you are talking to, implementing DDD has different challenges. One thing often mentioned is that the domain objects need to take care of their own persistence. All hard things to inject data access components into the domain object are considered by these people. I do not believe in that direction. I’ll take away transaction, security and persistence from the domain entities. The application services take care of the transaction boundaries and repository objects take care of the persistence. The post from Allard about the repository interface gives you an idea. More posts on this topic are coming.

A few things to think about while implementing

• Make sure the domain expert available to the team.
• Make sure the designers are writing the code as well.
• Let the model drive the code.
• Use the domain expert while coding. Spotting code duplication might be a misunderstanding in the model. Talk to the domain expert. This is also the case when you want to do a refactoring in the model.
• Create intention revealing interfaces and side effect free functions.
• Make the left side of statements read the same as the right side:
  Itinerary truncatedItinerary = itinerary.truncatedAt(routingPoint);
• Use Equals and HashCode methods as they were meant to be used.(see blog post Allard)
• Learn from other solutions, for instance infrastructure mechanisms for repositories.
• Do not try to copy domains. Most certainly they have been used in a different context. Of course you can learn from other models, use them for inspiration.

DDD is Domain Driven Design, it is not called DDI (Domain Driven Implementation). Do not come to me and tell me that it is impossible to implement DDD. If you are designing an application that cannot be implemented, that is a whole different problem.

Final remarks

• Do not design for technology, design for the domain.
• Use short feedback cycles with the domain expert, test first and verify solutions with the domain expert.
• Do not loose all technical perspective in design, but let the domain guide you in technical choices like: remoting, caching, transactions boundaries.
• The biggest impact in domain driven design is that your code can be understood by domain experts. That way problems in your code can be solved like in the domain. So you can actually copy the solution that the domain expert has been using for years into your design.
• The developer cannot make domain driven design a succes on his own. He needs the complete team.
• Make sure the design and implementation are tightly coupled.

That’s it. I hope I inspired some of you to have a better look at DDD. If you are living in the Netherlands you can attend a tech evening of JTeam, we will give an introduction into DDD. You can send an email to techmeeting@jteam.nl if you want to attend (3 september 2009, we start at 16:00). Another thing I would like to bring to the attention of the dutch readers is the DDDnl usergroup. We are planning our first session the 8th of september 2009. You can register yourself for the usergroup and for the session on the homepage of the usergroup. http://www.dddnl.org