Trifork Blog

Axon Framework, DDD, Microservices

DDD and modern software development

September 8th, 2009 by
|

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?

CE576EB1-08A2-409D-817B-94F3A8779D8B.jpgAfter 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

9309B773-A867-438E-8DDC-B1DD6A782C4E.jpgI 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.

primatras_logo.pngFor 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)

dddnl_logo.pngBecause 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.

Hope you like the article, feedback is very welcome.

7 Responses

  1. September 9, 2009 at 15:04 by Nuwan Chamara

    Nice article….. Learned a lot…. Thanks…..

  2. June 9, 2010 at 19:56 by Dave King

    Do you feel that a general understanding of the domain model is required before launching into your first sprint? Or do you stick strictly to the scrum methodology and only model precisely what is included in your sprint?

  3. June 10, 2010 at 12:31 by Jettro Coenradie

    To my opinion you should have a basic understanding of the model to create. You can learn about the model by reading about the domain, talk to you domain expert and of course go through the stories to create. I do not believe in one sprint at a time thinking. Think ahead, but do not make assumptions that you might need something in the future.

    Thinking about the domain is easier when you make small steps, especially if you are not very familiar with the domain. Make sure to know how to refactor your domain model.

    If you are going down this path, I urge you to have a look at our posts about CQRS and the Axon framework. This can help you a lot in creating a very well architected application.

    regards Jettro

  4. February 1, 2011 at 17:40 by SaaS

    good post, have you heard of mind mapping, this sounds a little like that. I have read about mind mapping and even done some study about it. I do know that the scrum method is great, we use it as well and it just works. Thanks for the post.

  5. May 25, 2012 at 12:27 by John Simpson

    The information in your post about Software is more interesting. and this info is more useful for the developers to develop the Software. Thanks for share this valuable info

  6. November 19, 2012 at 05:25 by Geo

    I’ve never worked with agile dev. , but sounds pritty innefficient to modify the model each time the customer comes with a new/radical ideea. You might spend more time on refactoring over and over again than on the actual development of the software. In my opinion Scrum works best with atomic services (SOA) not with DDD (the whole big picture). Some companies also specify when recruting SCRUM devs. that a service oriented mind would be best for the job.

    • November 22, 2012 at 12:27 by Jettro Coenradie

      I do not agree. The new radical idea will lead to changes, but in a different architecture this would be the same. You will always have changes and I haven’t seen a project that was clear from the beginning and never changed during the project. Therefore agile is a good approach also for a DDD project. I do think you have to think wise and talk with the product owner about the problem domain and possible future directions that have a big impact. Still nobody knows the future, therefor being agile is an advantage.