Well I think the interesting thing is that now it has been about five years since the book was published and so whereas at the beginning there were a lot of people around who were really experts in domain driven design, but never knew it by that name, because I did coin the name, for a design approach that existed for a long time. And also without the structure and the language that was the purpose of writing the book to kind of distill that approach. So we had those people who were good at it but we didn't have people who had a structured way of looking at it or approaching it. Now five years since the book has come out, there are actually people who have been working with this for years now. And they are starting to have things to say as well.
So this week we had two tracks at two different conferences, where we had a lot of really good presentations by people who are DDD experts and who have pushed the boundaries in one direction or another, discovered things that work or don't work, and so for me probably the most interesting thing is that now there are people out there that I am listening to their talks and learning new things, so that is quite exciting.
Usability of course, thought of it as a user interface design issue which of course it is. And so people say: the domain layer is down here, the UIs up here and many people say user model or domain model. I reject that separation; I say that there is a model. It's the way of thinking about this software and I want to find a model that makes sense to business people. Now there are situations where you have quite a different model in the UI than you have underneath. But I think that the first approach should be to keep the two together. But I need to say that I don't mean by this a sort of naïve "Well you've got an object so there must be an aeditpanel there, something for that object or that tab goes with an object or anything quite that direct".
Really the key is this ubiquitous language. This language that you can use to talk about the domain, which is based on the domain model of that domain. And that language should appear in the UI and the structure should be there, the rules should be there in the UI and so to me the conversation that happens as the software is being developed, should bring us to a place where we can talk with real clarity about what that software does. And I think usability comes from clarity. If someone can look at this software and really understand the concepts, the boiled down simple concepts, that underlie how it works, the software is more likely to be usable. Usability isn't just a matter of putting the buttons in the right spot on the screen, it's about having a clarity of concepts that allows the user to understand what the software is really going to do and what the presentation that it gives them really means. So I think the two go together in a very important way.
I was and am somehow agnostic of technology but maybe agnostic isn't quite the right word, I think skeptical is probably more my position. I think that a lot of time people go at problems looking for a technical solution to problems that are not fundamentally technical. But, good underlying technology actually helps with domain driven design because good in my definition means that we don't actually have to pay a lot of attention to it: it works and gives a simple way of using it. As far as multi paradigm goes, I think that in an ideal world we would be able to choose a paradigm that fit the problem very well, and we could as you say pick and choose depending on the particular problem we are addressing.
In practice one of the things that limits that, I mean there are many things that might limit that, and one of the biggest would be that paradigms are hard to master. For example, assuming object oriented programming in Java or C sharp or whatever, this takes a lot of time to master and if you said "Well this problem I think may be a logic based solution which fit better, but you might also this well but you know how to make a logic based system work better", work, because it's a different way of thinking, it takes a lot of training, there are all sorts of reasons that might not work as well as it seems like it ought to, in principle though I think it would. And also you mentioned context, I am not sure if you mean it in the sense of bounded context, a pattern in DDD, or if you meant it in a more general way.
In the case of context as in DDD I think it is actually more likely to work because there we have very sharp boundaries within which almost anything could be different. And probably it's a different team working on that context, but that might mean a different skill set, and of course these sub systems are built at different times so that you might have different histories and you may well find that you have a team working with two quite different technologies or two teams working with two quite different technologies, on a project and I think there is a case where the bounded context concept helps to keep things getting muddled, and so I could easily imagine that you might have chosen those technologies based on the sort of problems you were addressing into context.
When you talk about multi paradigm development within one context, I can see it in theory that there is no reason in theory that you might not want some objects and some rules and some whatever else all wrapped into one coherent model. In practice the technologies don't mesh that well, and the teams haven't usually mastered all these paradigms, so in practice I think that it often doesn't work out. I have no objection in theory, but this is what I observed so far.
Domain driven design is very test friendly. I am a big fan of test first at various levels. On projects that I am involved in we have unit tests and those of course are as you say not very accessible to the domain expert, but we have them because they are an important part of design and you can really use them to drive the fine grain development of your model objects and so forth.
But technologies like Fit and Fitness which are more about how the system works as a whole, these can be very helpful in the sense that they can actually be readable by non technical people, and they the best use of them for me is expressing a whole story, a whole scenario, beginning to end, but they are also used to test a whole stack of functionality as opposed to just one little unit. You definitely need testing about the level of unit tests, and sometimes fit or fitness is a good fit.
7. Yes.
That would help in the sense that the people who are tasked with writing the tests are probably familiar with that language. I don't think that it is essential. What would be essential would be that their relationship, the things you have to do over here to make the test work, is very clear and simple but of course in practice it could usually be the same language I think, that you would write fixtures that are in the same language as your tested program.
I don't think that domain specific language is the ubiquitous language, I think that probably the most fundamental place that the ubiquitous language lives is in spoken languages. So, the language that people talk, and actually how they talk to each other on the project, both between developers, between developers and domain experts and so on. And then we want to also write code that is expressing this ubiquitous language that is written in the same language. And in Java you can approximate this if you craft your objects very well.
So the goal of the domain specific language would be to allow you to come much closer so that the language you speak and that the language you are writing the code in are much closer together and hence this would be a more perfect expression of the ubiquitous language pattern. So it clearly has relevance there and one thing that I am more aware of now I think than in the past I think that it is important to realize there is a whole spectrum of approaches to domain specific languages some of which are kind of heavy in the sense that they would be a totally separate compiled language. Those might really be great in the future and I can see they are certainly applicable to some problems. On the other hand of the spectrum you have basically carefully crafted code in your own language that reads almost as if it's a domain specific language.
And that is something that I think that the best programmers do already, in fact that was probably what I had in my mind when I originally wrote that ubiquitous language pattern. And then I think there are beginning to be some things in between those things that sort of languages that have extensions that allow you to make a little more readable kind of code. So assuming that you are on this more lightweight end of the spectrum I think it is very much part of fulfilling the ubiquitous language pattern to say that I am going to go to the trouble of constructing code that lets me make statements in my programming language that correspond closely to the way I talk. And the closer you can make that correspondence the more ubiquitous the language is. Then DSL is still an area where you don't know completely what it is yet, I think. So it's hard to say more than that with any kind of certainty I think it's a very exciting area, I think it will be important in the near future but I couldn't really say anything too specific because I think it's so much in flux.
On this I will draw primarily from my own experience working with clients who are trying to introduce domain driven design or improve the way they use it. And I think that there are a few things. The one that I think is the most fundamental is that in order to do domain driven design or really any kind of sophisticated design you have to have a really clean context to work in, you can't do this in a middle of a messy legacy systems, you can't do it in an environment where anybody in a hundred person organization can reach in and manipulate code. You have to have a degree of isolation.
And for this you need to first do a context map, which is described in the book in chapter fourteen in case people don't get that far, and decide where your new work is going to exist. Is it going to be done in one of the existing contexts, is it going to constitute a new context? Which often will be because the point is to try and escape that stuff. And how is it going to relate to the old stuff. So establishing a really clear bounded context is one of the most important things, another is that most organizations want to introduce this through a pilot project, I think that is the best thing to do and this pilot project needs to be carefully set up.
In addition to having a clear bounded context they really need to not have any weak members of the team, they need to start out with some of their best people. It isn't that you can never accomplish anything with the other people, but starting anything new is difficult and this is a difficult thing. Then choosing the problems is really important to getting things started. They need to choose the right kind of problems for that initial pilot, it needs to be something with a little bit of intricacy in the domain, not a CRUD project, it also needs to be I think an important project, a lot of people would choose a low risk low visibility project for pilots, because it reduces the impact of failure, but the trouble is, it also reduces the impact of success.
And the very value of DDD is so much about what is it that you care about in this domain that to choose one of the supporting domains that kind of peripheral thing or supporting thing actually defeats the purpose. At the end you may succeed in the sense that you may produce some software that works but you won't have succeeded in the sense of demonstrating that the approach works, because the whole point of the approach is to stay in this areas where people where you are really close to the bone of what matters most in this domain that we can establish this communication between technical and business that gets you somewhere that you wouldn't otherwise have gone and creates business value there. And so you have to have something that has business value.
So I think to sum up: you want to start with a pilot project, you want to make sure that they're operating in a clean context, well defined boundaries and well defined relationships in existing systems. You want to choose a project, a task for them, that is not too big of a scope of course but something with some intricacy in it because otherwise modeling is pointless and something that has significance to the business, so that the right kind of orientation is established from the outside and established in terms of we are going to focus like a laser on what is most important to this business, and those are the basic steps. I mean obviously there are a lot of things that might matter but that gets you set up at least for a successful rollout.