DDD and modern software development

One of the main things we do @ jteam is creating rock solid custom development. Of course we use proven frameworks, we keep innovating and we use a lot of the best practices for custom software development. Best practices I am talking about are: Continuous Integration, Test Driven Development, Peer reviews and of course Scrum. I guess I could use more buzz words in there, but that is not the scope for this item. So I am not going to talk about cloud, soa, virtualisation to name a few. This post is about why DDD is a match made in heaven with custom development.

What is DDD?

For those people reading this blog item and think: “What is DDD?“. DDD is an abbreviation for Domain Driven Design. We have been writing about DDD before on this blog: “The misunderstanding of domain driven design“, “Domain Driven Design applied“.

The most important thing to know about DDD is the strong correlation between what the domain expert talks about in his normal working day, the design, the code and the tests. Even when talking about the project during a coffee break, the same language is used. This is what we call the Ubiquitous Language.

Another big part of DDD is creating the model. Since we are going to create a software solution for a problem in the domain, we need a form of simplification of that domain to base the solution on. This simplification is called the Model.

You have to know the context to understand the model. Some concepts of the domain can be important within one context, but not in another. Think about a cinema and a system to support buying a ticket. The ticket buying system needs the concept of a person buying a ticket. The seat allocation system does not need the person, just which seats are taken. Both systems deal with seats and people that want to watch a movie. Within the context of buying you need to have information about the person, within the context of seat allocation you don’t.

The central part of DDD is communication between the domain expert and the developers. The knowledge of the domain expert needs to be used while designing as well as coding a solution for the problem to be solved.

What is custom development?

After this very brief introduction into what DDD is about and what the intentions are, let us discuss custom development. Custom development to me is everything more than having a product that needs to be configured and needs one or two adapters to make the product integrated with other systems. Custom development is about creating a new product. The product should be a perfect fit to the problem of the customer. Compare it to a closet you can buy at one of these big stores like the IKEA. Can be a nice closet, with some doors and drawers. It fits alongside the wall you have in mind, and it can be used for storing things. But you know your neighbor could have the exact same closet. The color could be off, the number of drawers is not exactly what you want. In short, it is not the closet you ever wished for. A solution to this problem could be to go to a carpenter and let him create the best closet you have ever seen. He asks what you want, what you want to use it for and how it must look. After a few months and a lot more money than that closet from the IKEA would have cost, you have the best closet ever.

Before the carpenter starts crafting your closet, he needs to know very well what you want. Often a sales person is between your idea and the carpenter. That sales person not know everything possible about the options that you might have. It could well be that the carpenter cannot create what you want. I personally have an experience in this area, we had a closet that was not what we asked for because the sales did not design the closet in a way the carpenter understood it. They also did not talk about it to verify if this was what I really wanted. More over, I did not talk to the carpenter to explain him what I wanted.

What does this have to do with creating fine software. A lot. When creating custom software you have to talk to the customer about what he wants. We, as software designers, must always talk to the domain expert to learn about the domain (what is the closet going to be used for). Of course this “talk to the domain expert” is also true for package based solutions. The freedom that you have related to custom development is much smaller.

So what is important for a good, custom developed, solution? Of course you need a lot of common best practices like: Continuous Integration, Test Driven Development, Quality control, pair programming and JTeam (sorry could not resist). In itself none of these practices will give the customer what he wants. You need to combine these practices with a good process. At JTeam we strongly believe in light weight agile processes. Our own projects are executed using scrum. To be sure you create the best solution, give the customer a lot of feedback moments. We always work iteratively, or within scrum terms, in sprints.

The final step in creating well developed custom software, is to actually understand what the customer wants, and build exactly that. Wouldn’t it be nice if the customer could actually read the code and help the developers to make it better? Of course it would be nice. The solution to that problem should be obvious by now. We use Domain Driven Design to make that happen. Therefore DDD is not the best thing that a developer can learn, it is the best thing that can happen to the customer. That carpenter would have created a much better closet if he would have consulted the domain expert of his customer. My wife knows very well what she wants to use those drawers for. (In reality most of the stuff in the drawers is from me, but this does make the example better 🙂 ). If the carpenter would have talked to my wife, we would have a better closet and he would not have given us a discount. He could also have sent us some pictures while he was working on the closet. To give feedback about what you are creating is very important to come with the right custom built solution.

DDD together with Agile practices

I am not going to heavily describe what Agile is about. There are so many resources about being agile that I invite you to use google to find out more about it. Within JTeam we prefer to use Scrum for our projects. We like doing sprints, work with a backlog of items to be done. Just like with DDD, Scrum needs a good involvement of product owners to make it a success. Scrum has the goal to deliver working software every sprint. That is only possible when making small steps. Just like DDD, Scrum works with stories. DDD uses stories to create and verify the model. Scrum uses stories to determine the scope for each sprint, write tests and running software. Both DDD and Scrum use tests to verify if everything works. Scrum uses tests to verify if the story is implemented, DDD uses tests to create a good API. Both prefer to write the tests before the actual code.

To me, agile practices like those from Scrum, strengthen the DDD offering. Together they give the customer what he really wants. If something goes wrong, you notice at least after each sprint. Using the domain expert, the risks for doing something completely wrong are little. Be sure to make it possible to make mistakes. Especially in big custom developed systems, you need to be able to make mistakes to create the best possible solution. Refactoring is part of the agile practices, use it to make the design and code a better reflection of the domain.

Why is DDD the best thing for a customer?

By now you should have a basic idea why DDD is the best thing for a customer to happen in his project. The customer gets a custom made software solution that tackles the biggest problem of his business. Because DDD is such a nice fit with Agile practices, he will have a lot of influence on the process as well as the end product. One thing that I learned by experience is that using DDD, the domain expert can help improve software and to understand what has been created. Let me explain what I mean by an example.

For a friend of mine I am creating a backoffice system for his online store. This backoffice has been in production for quite a few years now. We keep on extending it and every now and than we need to make changes to functionality I have created years ago. Since I am not the perfect programmer (who is?), there are some pieces in the software that are not documented well enough, do not have enough unit tests and are just not clear code. When I started to create the backoffice I did not use DDD. Not all terms I used in the code were the same as my friend uses in his day to day business. When I had to make a change in the workflow of the order, we had a very hard time trying to find out what the process actually was and relate that back to the code. Of course my friend knows exactly how he runs his business, but that was not reflected in the code. So he could not help me to explain what the code does. If I had been closer to the domain in the code, he could have explained me very well what the code has been doing.

To me that is the most important aspect of DDD, make sure that the design and code are based on the domain in a way that the domain expert can help you understand the code. Of course that should not be a reason not to document the code or write crappy code. Since he can only explain the concepts.

What do we need from a customer to make DDD a success?

There are a few things you as a customer must take care of in order to make this DDD thing a success.

• Work with an iterative process, we prefer Scrum.
• Make the domain expert(s) available to the team, preferably face to face, during the complete project.
• Provide a domain expert who can make decisions, not someone who has just started and needs to ask everything himself.
• Make the project a shared effort, preferably not fixed time and fixed budget. Try to come into an environment of trust between customer and supplier where each sprint should be a moment of evaluation of the relationship.

What are the next steps?

Ok, you have read this article. (warning: start commercial part)If you want to learn more, feel free to give us a call. We love to do custom development and we are good at it. We can show you what we have done. One of the things we like to do is have an open discussion with your domain experts to talk about their problems that need to be solved. (end commercial part)

Because we really believe in Domain Driven Design, we have started a user group in the Netherlands. We are looking for members that want to learn more about DDD and/or share their experience with DDD. Have a look at http://www.dddnl.org. We are planning to organize events in the future, if yo have ideas let us know.

There are a lot of other resources to learn about DDD, you can start with the following website.

• http://www.domaindrivendesign.org/ – Home page of the DDD community.
• http://www.dddnl.org – Dutch DDD user group
• http://en.wikipedia.org/wiki/Domain-driven_design – Home page on wikipedia with a lot of links to other resources.

Hope you like the article, feedback is very welcome.