“It takes a day or two to gain from DDD, but a lifetime to master”
What is so appealing about Domain-driven Design and what are the typical problems one faces when trying to apply it to real projects? In the context of the microservices debate, there is a sort of revival of the DDD principles. What is the difference between DDD and microservces? We invited Jimmy Nilsson, author of “Applying Domain-Driven Design and Patterns” to answer all these questions and more.
Domain-driven Design: Not just “another framework”
JAXenter: The concept of DDD was coined in the early 2000s – you contributed heavily with your book „Applying Domain-driven Design and patterns.“ When you look back at the pre-DDD times: What problems did the space of software development / software design face to which the methodology of DDD provided a solution?
Jimmy Nilsson: Back then I think the first important effect of DDD was to provide lots of useful tools for dealing with the difficult task of creating rich domain models that were good. I (and several with me) had been struggling for years with that and DDD came as a huge boost.
But even more important (actually much more important) was the philosophical aspects of DDD. For example the importance of collaboration between software practitioners and domain experts and trying hard and everyday to create shared understanding of the problem and the chosen solution. I think that – togetherness and shared understanding – is still the most common thing I stress in different projects I have a look at or are deeply involved in.
I expect to have use for DDD for the rest of my career. It’s quite the opposite of “yet another framework” that come and disappear after a year or two.
JAXenter: What was so appealing about DDD for you personally?
Jimmy Nilsson: Well, there are so many things. I think DDD together with TDD has been the two most important things for making me a better developer. Anyway, if I pick one thing spontaneously, I think it’s very appealing with DDD that it’s yet another example of that it takes “a day or two to gain from it, but a lifetime to master”. I expect to have use for DDD for the rest of my career. It’s quite the opposite of “yet another framework” that come and disappear after a year or two.
JAXenter: Very often, developers know the principles of DDD quite well – but it is not trivial at all to put them into practice. In your experience, what are the typical problems one faces when trying to apply DDD to real projects?
Jimmy Nilsson: A very typical problem is that DDD is used in real projects as a technology style only and in a very prescriptive way. It’s just not going to help a lot, but at the same time it will be quite challenging to developers. The effect will be low productivity and little gain.
JAXenter: Do you have a tip for our readers how to tackle those typical problems?
Jimmy Nilsson: I propose to focus on the collaboration instead and to investigate the problems and solutions with different models. Play with those models, try them out. Expect them to change and improve over time when you apply them.
JAXenter: With your book „Applying Domain-driven Design and patterns“ you bridged the gap between Eric Evans’ DDD concept and Martin Fowler’s Patterns of Enterprise Architecture. Do you think this gap still exists today?
Jimmy Nilsson: Definitely! I do see more situations where the gap is smaller, but in the majority of cases it’s still a big gap.
JAXenter: When we look at today’s discussions about software architecture, DDD is still very relevant. In the context of the microservices debate, there is even a sort of revival of the DDD principles. What do you think about microservices? Is this the logical successor of DDD – or do you see a big difference between the DDD and microservice concepts?
Jimmy Nilsson: I’m for many situations very fond of what I call the bounded context-style of microservices. I wrote this article in 2009 which still describes quite a lot of how I think of microservices (although the description of storage is dated). But “microservices” is a better name for it, definitely. :)
A very typical problem is that DDD is used in real projects as a technology style only and in a very prescriptive way.
JAXenter: Which aspect of DDD is mostly underrated or neglected in today’s software development praxis?
Jimmy Nilsson: I realize that I’m repeating myself, but I think togetherness and shared understanding is the answer to that. Another aspect, and that’s coupled to microservices, is the “strategic design” of DDD. It’s extremely useful for example when taking on a troublesome, large and messy situation and helps a lot with how to deal with that.
JAXenter: What is currently your main interest in the field of software architecture, methodology?
Jimmy Nilsson: My current main interest is to create company specific languages that are *helpful* for the collaboration between domain experts and software practitioners instead of the ordinary C#/Java code which is more of a hinder and a translation gap. The descriptions in the company specific languages are then executed with company specific engines that are providing the architecture that is needed. I find this very interesting, especially because the potential positive effects are so large.
Thank you very much!