These days I am doing my consulting work, helping different clients with Domain Driven Design, either by working out their strategies, sometimes training and, of course, I'm going conferences like Spring Experience.
2. For the uninitiated tell us what is Domain Driven Design?
The essential thing about Domain Driven Design is that you have to care more about the business or the domain that the software is being targeted at, then you worry about the technology or whatever technique, or even the process that you are using to develop the software. That is the domain driven part. But it is a lot harder to do it in practice than just that simple statement. So there are great number practices that feed into it and of course when the domain gets complex, modeling of the domain is the key to managing that and that is why there is so much association between Domain Driven Design and models.
I would say there is a lot of latitude but the most fundamental pattern of Domain Driven Design is probably the ubiquitous language. So that means that as we refine the concepts that we are using to deal with the domain in our conversations with domain experts, with the experts in our business, we speak a certain language and that language is being refined all the time, reflecting the refinement of the concepts and that we are using that same language when we talk to the other developers, to the architects on to the team. It is the same language we use in the requirements document and therefore the requirements documents have to be refined as the conceptual model is refined and quite importantly it's the same language that we use in the code to whatever extend that the technology will allow us; we try to make that correspond to the ubiquitous language, that's why it's called ubiquitous because it's throughout the process. But then to go with that you have to have a recognition that there are boundaries, that a model is not just floating in space, that it applies within a certain context and that context has a definitely defined limit, a bounded context for the model. With those two ingredients I would say someone is doing Domain Driven Design and there are a lot of other practices that help solve more specific problems.
That really varies a lot depending on the kind of implementation technology you are using. In fact one of the advantages of object oriented programming is that it allows a closer correspondence between certain kinds of models and conceptual systems and the language that we tend to use and the actual implementation. So sometimes in Java, for example, you can write code that although it's syntactically quite different from the English sentence, it might have similar meaning. So you could read that line of Java code in a carefully crafted object oriented system and say: "I know what that means, I could explain what it means using very similar words, using English syntax." So that's one of the basic advantages of object oriented programming, but it is still limited. You can say subject-verb, but there are other things that you might want to say and that is one reason why people want to explore other technologies like Domain Specific Languages and all sorts of other approaches, but I suppose that that's where we're at today.
5. Tell us more about bounded context.
A bounded context is one of the fundamentals and it's one of the things that people don't think about very often. They think about models, but they don't think about what is the condition that gives this model meaning, what is the context. If I say: "I want to go home." and I am sitting here in this hotel, it probably means I'm going to go to the airport, I'm going to get in an airplane and go to California. If I said: "I want to go home" and I'm standing on a baseball field, it probably means that I want to run around the bases and score a point. And people don't think about that so much when they are writing software, designing software. That the meaning of even a simple English statement and certainly the meaning of domain objects that you are designing is very context dependent and so a bounded context is an explicit recognition of that, saying: "We are using this model within this context" and I might define it by a subsystem. I might say: "Within this subsystem this is the context - I mean this is the model that we are using." or I might say:" "Within the work that this team is doing this model is being applied". It often corresponds to team boundaries because these are also conceptual models and you can't share it automatically with other people, you have to have a close enough association with them to really mindmeld. That's essentially what a bounded context is and there is always more than one model in play in a project of any significant size and so boundaries are important or else things start to mix together and you get just a meaningless mush.
That is a good question. Usually they are not and that I think is the problem. As far as the ubiquitous language goes it does tend to be carried in the air. Sometimes people come up with glossaries and things. I think people have to be careful about that because a glossary can freeze the language and part of the value is the evolutionary quality; but as far as the bounded context go, which actually tend to be more stable by far than the ubiquitous language itself, once there is a lot of code around, established teams within organization even departmental boundaries, the bounded context tend to be pretty stable. I actually diagram that out in a kind of informal notation similar to what I use in the book and I am not prescribing a particular notation, but I am saying it is valuable to actually draw a picture, get some people together usually architects and project managers and a few key costumers maybe can get together and they can draw what their context map looks like and share with everybody, all the members of the team; this is well worth doing and in fact it is one of the things I frequently do with costumers, with my clients.
I have been talking about that quite a bit lately because it's really been on my mind. I became more and more aware that one of the basic mistakes that model enthusiasts made from the start was the idea that we should just model everything, that the whole system should modeled and object oriented and so on. what I have started to realize is that that dilutes the effort to the point where we don't really ever get the bang for the modeling buck and that in fact both systems are probably 90% CRUD (create, read, update, delete) and that there are simpler solutions to that problem, so what I have really been looking at is zeroing in on the difficult complex parts of the domain, the complicated part is really causing problems and focusing the modeling effort there and using this bounded context idea to divide that from the other parts and then within a few high value difficult problems you really see what modeling can do. You really get a lot of value because it's a difficult process, it's not something you want to do just for the fun of that, you don't want to do it for the hundreds and hundreds of screens that just collect data and slam it into the database. You want to do it for the parts that are going to really pay off for the business.
8. When you say modeling, do you actually mean you UML modeling or do you mean writing classes?
It has become almost anonymous that modeling is a UML diagram or maybe that it is the layer of the software, but to me modeling is much more fundamental than that. A model is a conceptual system; it's a set of abstractions that you can apply to some specific problem or set of problems. You know there were models long before there was software and physics theories are models and maps are models of the world and they are used for specific things like maps for navigation, maps for doing demographics and by the same token we make models of our domains which are highly distilled, rigorous, selective choices of concepts from the domain that we find useful to either illuminate some particular important piece of information or work on some particular problem. I know that sounds vague but it is really what a model is, I mean if you look in the dictionary it will be something like a system of abstractions but part of the power of models is getting back down to that basic definition.
UML is a good way of communicating or recording certain characteristics of some models. So since we're operating mostly in the object oriented paradigm the types of models we choose are like: "Well, we have this set of things, this set of objects and they are related to each other in these ways and they interact in these ways and so UML has notation and lets you illustrate that and especially in terms of the static relationships among objects. It's a good communication tool. I think that as long as it is used for that it's a real asset, and then though on some of the other aspects of model it actually gets in the way, such as when I was talking about connecting the ubiquitous language with the code or just the ubiquitous language in general is more of a textual kind of thing by nature. So then sometimes plain old Java code is clearer actually than you UML diagram that tries to convey some sort of relationship that is more dynamic.
That's something I have been puzzling about myself because I have noticed there has been a surge lately. I think part of it is that people's awareness was heightened somewhat by the book and it had to be some period in which people absorbed this new presentation of the ideas and now they have had time to try some things out on their own and now they are starting to see this bubbling of other people taking it to the next step. So I think that might be why there was this lull and that takes several forms, one is new books coming out like Jimmy Nilsson's: "Applying Domain Driven Design and patterns" book and then InfoQ came out with their Domain Driven Design quickly summary version and also people are just out there using the techniques; there are some interesting experience reports people have started to write and another interesting thing that is happening of course is that the tool makers and technologists are trying to do things with it and that sometimes there is a wide range of approaches to that and sometimes it's a disaster but some people now I think are doing things that might actually make the technology platforms a little more suited to Domain Driven Design. Anyway I am excited to see the experimentation. I am big on experimentation and we'll see what works over the next couple of years.