1. Can you tell us a bit about yourself and what you are working on?
I'm a Swedish guy living in the South of Sweden and I've been a developer for the last 17 years. Except for my main business, development, I also teach a little bit and do some writing. I'm currently writing a new book which will be called "Applying DDD and Patterns"
2. What is Domain Driven Design?
As I see it it's reusing or taking the good habits from Object Oriented Design, the good Object Oriented Design and putting them in a new package so if you have been using object orientation for a long time you will recognize lots of the ideas in Domain Driven Design. If you just get started building a domain model without knowing about those ideas you have a big risk of creating a huge ball of mud which is extremely connected to main model, everything talks to everything, which will be a problem quite fast. Domain Driven Design is about avoiding that problem. That's one thing about it. Another thing about Domain Driven Design is to have an extreme focus on the domain, so you try to learn as much as possible about the domain and you try to put that new knowledge into the code. So it's not so much about translations; you try to use it as it is, to avoid all these gaps between business experts and developers for example.
3. What is new here giving that we already know Object Oriented Design?
Perhaps not that much actually. There are a lot of old concepts, but nicely packaged together I think. Perhaps the focus on the ubiquitous language is a little bit new, which means trying to come up with a single distinct language that is shared between the developers and the business experts. A language so that the concept of customer has a very distinct meaning to all people in the project, because when you talk to your business experts from the same company most of them probably have a pretty different understanding of such concepts. We try to distill that. We try to come up with one single definition and also using those concepts definition within the code as much as possible, which will help us absolutely in the long run.
Perhaps that's a bit new, but it's just using a lot of old good ideas from our backdoor end to design actually. To old experienced developers is not so much new. Another thing is that we get new names, new distinct names on the ideas, which is good; it helps the language between developers. When I say the aggregate pattern other people knowing about domain driven design understand directly what I mean. From the beginning I didn't realize the importance for the names of patterns, but now I think it's extremely important. Perhaps it's the most important thing about patterns: to create this common language between developers.
4. So what is the value proposition of Domain Driven Design?
I think some of the most important advantages of using it are: the maintainability story will be very nice because you put a lot of energy into creating a clean core model without technical distractions which will help your maintainability of course, because the model is as simple as it could be. When business changes you have tried to describe that business in that core model as close as possible or you have chosen the abstractions you want to use and when it's time to make changes to business it will be as simple as possible to make the same changes within the code. That's one thing. The other thing that comes to mind is that Domain Driven Design is pretty much about creating test friendly design which I think is an extremely important goal these days. If a design isn't test friendly, it's bad. So test driven development goes very much hand in hand with domain driven design in my opinion.
5. Is Domain Driven Design a process? How does it relate to Agile or unified?
I think Domain Driven Design goes hand in hand with Agile pretty much but I wouldn't say it's a process, perhaps part of a process. It's about taking in the business experts within the project so you create a team, very much as in the Agile movement. There shouldn't be two teams with translations and conflicts. You should be one team, but I think you could use Domain Driven Design with any process actually. That's how I see it. It's more about design style more than about the process in my opinion.
First of all it's like in any project. You need to gather and understand the requirements; in the beginning you have to talk lots and lots with the business experts and try out ideas, do some sketching together. I think compared to other ways of doing this, there will be much more working together during the whole project with the business experts. So that once we the developers have understood something we can directly check that with the business experts. And that's what we do during the whole project.
The project starts and more or less ends the same way, if we work together trying to distil the concepts, trying to create this ubiquitous language. Of course we cannot do all that early on and then just use that knowledge building in code afterwards. It's an ongoing iterative process: we learn, we try it out in our models, we write some code, check it with the business experts to see if we are on the wrong direction. Probably together we also come up with new ideas about their business (not something to forget of course), do some process improvements as we go. We shouldn't just listen to them.
We should of course try to make some changes to how it could be done even better for example. Perhaps not huge differences to what most of us are used to actually; it depends very much of what you are used to of course but I'm sure many will recognize this as "Well this is what we do all the time". But putting emphasis on the collaboration with the business experts, that's at the core of Domain Driven Design.
You can't wait for the GUI for example until you have the complete Domain Model. It's something that has to be done at the same time, in parallel. I also think that there are lots of different activities that will help you better understand how the domain model should look like. It's not just talking to the business experts; it's also when you need to add GUI for example or add services. That's putting another angle to the problem. It will always help you to understand that you haven't understood a certain thing. The same goes for persistence; I think you should delay the persistence problem in the project, just a little bit, but you shouldn't wait until the last few weeks because it will slightly change your domain model, absolutely. It will put some requirements on you, which means that you should do all things in parallel to some degree.
8. What are some of the challenges faced when applying Domain Driven Design?
There are several I think. First of all it depends on you team, if you have a barrier or not, if you have a prior experience with it, it's not a problem. You're on your way directly. But if the team isn't used to this, you shouldn't underestimate the problem of moving the team into this way of thinking about it. For example I think very many organizations are focusing on database development and it won't take a week to move a developer from that way of thinking about approaching problems to this way.
It takes more time absolutely. That's one challenge. And another challenge is in technology I think, because one idea is to put lots and lots of time into the domain driven model itself (that's what you'd like to focus on, because it's about solving the business problems); on the other hand normally it will take you a lot of time making translations from the Domain Model to the persistent representation and you can't do that by hand because it will take you too much time so you can't focus on the domain model so you need some tooling there.
At least in .NET land the tooling for infrastructure to domain models hasn't been so good or it's not so mature as it is in Java land (I'm thinking about OR mappers) for example), but it's changing rapidly. I think that's another challenge: your team has to learn a whole new tool set probably, if they are not used to it from before. Two years ago most teams had to write all those tools and at least that problem is going away, to a large degree. I think these were two good examples of the challenges.
I think it's very much about concepts which means it's not focused on a certain platform; it's actually a big advantage of Domain Driven Design that it can be applied both to Java and .NET teams or platforms. It also helps in the long run to use Domain Driven Design when you think about all those technology shifts every second year or something like that; because your core model might say the same, it doesn't really matter if you have a new platform version, it's not important. It helps you regarding maintainability not to have the dependences on their platform in the core model a lot.
That's a good question. I think the movement we've seen in Java land (I'm not sure it's fair to say moving from EJB to POJO but I think you get a feeling of what I'm after here; the movement to POJO is totally inline with Domain Driven Design in my opinion). About infrastructure ignorant objects perhaps you would have a problem with the old EJB ideas together with Domain Driven Design. Again my focus is, from a longtime, on Microsoft platforms so I don't know too much about EJB but I understand there has been a lot of focus on distribution for example which Domain Driven Design isn't about at all. Perhaps it was a misunderstanding by the whole community, but I think that was the case with EJB, the fact that it was about services much more than it was about object models.
11. How did domain specific languages fit into this?
They will also benefit from Domain Driven Design. They can work together perfectly, they are in a symbiosis. One example of a domain specific language could be to let the business experts write the business rules in the context of your domain model, so that the only things those rules could be about are the concepts you have in your Domain Driven Model such as the customer, the order and so on. I think that would be a very interesting domain specific language. Again, for creating this collaboration, not having to bridge the gap between business and developers as much as possible, instead of giving the business a tool for helping out in the project, I think that's very promising actually. I really hope to try that out in the near future.
12. Model Driven Architecture. Are MDA & DDD in conflict?
I guess they don't have to be, but I have the feeling that they are at the moment. I think currently MDA it's pretty much about executable UML, which is not inline with Domain Driven Design ideas. The idea about Domain Driven Design is that the code is the model; it's a little bit the other way around with the MDA, it's the UML model typically that is the most important, and from that you can create executable programs. Perhaps we will see a merge of those ideas in the future, but I think Domain Driven Design people are more code focused than MDA people.
13. What are the top three impacts that Domain Driven Design will have on architecture?
It will be very much about the single responsibility principle or separation of concerns, if you like to call it that way. That's one thing which will change, if you have been using three tiers or N-tier architectures with a rigorous layering I think you might see that go away a little bit. The layering isn't as important, at least in my own designs. The third one is about moving out the infrastructure; perhaps that was my first answer as well. But I focus on thinking about the infrastructure, this is core and I'm trying to separate them carefully. That is something that is changing design very much.
14. Why are so excited about Domain Driven Design?
I think this feels so natural when you get started with it; it's capturing so much over your ideas of how things should be done, how you should approach development I think, capturing knowledge. There are a lot of feelings. It's more subjective than objective. I think most people giving this a real try like it very much. It's absolutely worth trying out. I recommend people doing that. That goes for Test Driven Development as well which we touched on; those two together are a very strong pair in my opinion.