Eric Evans on Domain Driven Design

Interview with Eric Evans on Sep 18, 2007

Community

Architecture

Topics

Language ,

Design ,

Modeling ,

Object Oriented Design

Tags

Domain Driven Design ,

Languages

Summary
Ever since Eric Evans wrote the book Domain-Driven Design in 2004 he has been a significant voice advancing domain modeling and design concepts. In this interview with Floyd Marinescu he talks about some of the recent refinements in Domain-Driven Design and how people are advancing the field today.

Bio
Eric Evans is a thought leader in software design and domain modeling and the author of Domain-Driven Design (Addison-Wesley 2004). He has specialized in domain modeling and design in enterprise systems since the early 1990s. He has coached and trained teams in Domain-Driven Design and has helped integrate agile processes and sophisticated design into diverse projects.

This is Floyd Marinescu here at the Spring Experience with Eric Evans, creator of Domain Driven Design. Eric, tell us a bit about yourself and what you are up to these days.

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.

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.

For a team that wants to do Domain Driven Design, what are the minimal sets of practices that they have to do to effectively practice Domain Driven Design?

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.

Briefly more on those two, first of all, how does the ubiquitous language translate into a code, what does it actually look like?

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.

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.

How are ubiquitous language and bounded context documented and how is this knowledge shared among the team?

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.

How have you noticed Domain Driven Design being overused and how do you know when you are overusing it?

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.

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.

So you don't mean UML?

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.

It seems that although Domain Driven Design came out in 2003 it seems that there is really a lot more buzz growing about it now. Why is now domain's driven design's time?

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.

 

1. Back to top

   gregory desvaux

   Sep 18, 2007 2:00 PM by gregory desvaux

   Thanks InfoQ for this interview. Pojo based programming model is just one of this breakthrough that helps developers focusing on the domain. Let's see how the whole IT industry is going to take domain into account. I hope we will soon get job description with DDD instead of the common buzzwords such as Hibernate, Spring ( for POJOs again ) J2EE, .NET and so on... When you know that Gavin King and Rod Johnson are praising DDD...

   Reply

2. Back to top

   Eric Evans will be at QCon San Francisco Nov 7-9

   Sep 18, 2007 9:57 PM by Floyd Marinescu

   FYI, Eric Evans will also be speaking at QCon San Francisco (Nov 7-9).

   Reply

3. Back to top

   An additional factor in the 'rise of DDD'

   Sep 18, 2007 11:40 PM by Chris Beams

   Floyd's last question to Eric in the interview speaks to the increased buzz around DDD today, and asks:

   Why is now domain driven design's time?"

   
   While I agree with Eric's answers, I believe there is another factor. It could be summarized as “the advent of POJO programming”, but I think it’s worthwhile to look into why this matters and how we got here.
   
   POJO programming matters because it frees up the domain layer in an application to deal with just one thing: complex domain logic. DDD counts on the existence of this layer, and builds upon it throughout all its design concepts.
   
   It’s taken several years for POJO programming to come completely into its own, and thus it’s taken a while for DDD to gain a foothold. Why the delay? Because it has taken time for the community to understand and embrace the ‘enabling technologies’ for POJO programming, which principally include:
   

   • 1) dependency injection
   • 2) object-relational mapping
   • 3) aspect-oriented programming

   In 2003 (when DDD was first published) the Java community was busy trying to sort out these relatively new ideas. New frameworks were becoming popular (Hibernate, Spring, etc), but were not yet mainstream by any means. EJB still ruled the roost, and AOP was ‘considered harmful’. Thrown into this already chaotic period of growth, DDD immediately attracted a loyal few, but naturally could not compete with the excitement and drama of slaying EJB or deciding who would win today’s persistence deathmatch.
   
   Today these technologies have gained wide acceptance and the arguments about them have largely died down, giving rise to widespread POJO programming and opening the door for DDD.
   
   In the case of OR/M, it’s safe to say the ‘persistence wars’ are over, and it matters little whether Hibernate or JDO (or now, JPA) won; what is important is that this *kind* of programming is commonly being practiced. These less-invasive persistence techniques allow developers to focus on domain logic, rather than “database access infrastructure that swamps the code” [DDD, p149].
   
   And likewise with dependency injection. While Spring today is about much more that just DI, it’s first claim to fame was undoubtedly its IoC container. Removing the need to embed service lookups, properties file access and other dependency-related code within domain objects has also allowed developers to think more clearly about the needs of the domain vs. the needs of the software.
   
   Aspect-oriented programming, while perhaps the least leveraged of these three, serves the same purpose: whether it’s declarative transaction management or simply removing rote method-tracing logging statements, AOP helps developers get boilerplate code out of their domain objects and into configuration.
   
   Ultimately, when these techniques are combined, they can serve to remove most or even all the code from a project’s domain layer that is not specifically related to the business of the domain. When this happens, many models are exposed for what they are: anemic in behavior. Developers can’t help but see that their ‘objects’ have been little more than very busy data structures. After all, when there’s nothing left in a domain object other than its constructors and data members, things start to look a little naked. Certain questions almost present themselves to the developer: Where is the behavior? Where does my business logic live if not in the domain layer? What are these ‘domain objects’ really for?
   
   Of course the answer to this is that the business logic often lives scattered throughout the service layer, or in transaction scripts or ‘manager’-style objects. The domain objects do little more than get populated, read, and ultimately persisted. The idea of consolidating that business logic into the domain objects begins to look attractive because POJO domain objects are freed up from distracting infrastructure code. They provide an ideal, centralized place for handling the complexity of the business domain. Object-orientation’s power to abstract and encapsulate that complexity can be fully leveraged, and everything else in the application (UI, database, service layer, etc) can take a backseat and serve the domain layer in a supporting role, rather than competing with it.
   
   The ideas put forth in DDD are high-level design concepts rather than specific technical implementation techniques. That said, these concepts only become widely relevant when a) the technology at hand can easily facilitate their implementation and b) there is sufficient community adoption and support for those technologies. Thanks to the last several years of the POJO programming movement and it’s enabling technologies we’ve now arrived at this kind of technical ‘sweet spot’ for DDD adoption, thus its current rise in popularity.

   Reply

4. Back to top

   Re: An additional factor in the 'rise of DDD'

   Sep 19, 2007 3:39 AM by Rickard Öberg

   Excellent analysis, and I agree with it completely. It will be interesting to see how frameworks adapt in order to better deal with these new possibilities of taking the data structures and transform them into real domain objects.

   Reply

5. Back to top

   Agile aproaches as an additional factor in the 'rise of DDD'

   Sep 19, 2007 12:07 PM by Juan Bernabo

   I think there is DDD time has arrived because more and more people are starting to use agile aproaches to software development.
   
   DDD and POJO´s can help us to apply the lean principle of delaying commitments, architecture and implementation details ignorance can be a blessing to add an enormous flexbility on how code will be used, and don´t commit too early to an specific technology or implementation detail.
   
   Juan

   Reply

6. Back to top

   Re: An additional factor in the 'rise of DDD'

   Sep 24, 2007 11:54 AM by Randy Stafford

   In my opinion, the "rise" of DDD is due to mindshare started by Eric.
   
   The DDD architectural style and approach to development is not new; Smalltalkers have been practicing it since the late 1980s (tech.groups.yahoo.com/group/domaindrivendesign/...). What has happened is that Eric has beautifully articulated that style and approach, and he and others have widely publicized it in recent years, as I remarked in my comment to the previous InfoQ interview with Eric (www.infoq.com/articles/eric-evans-ddd-matters-t...).
   
   Nor are DI and AOP required to implement POJO-based DDD. I began implementing POJO-based DDD applications in 1997, using the GemStone OODBMS for object persistence, long before DI containers and AOP technologies were available for Java. One example of such an application circa 1999 was FoodSmart (c2.com/cgi/wiki?FoodSmart).
   
   As another example, Floyd should recall that my chapter 7 in his 2001 EJB Design Patterns book originally contained pattern-based content on POJO domain layer implementation, including a persistence layer design that combined the Facade and Strategy patterns to allow pluggable persistence implementations while protecting higher layers from such variation. He removed that content prior to the book's publication because he didn't feel it was tutorial enough in nature.
   
   I agree with Chris' point on why POJO programming matters: it removes accidental complexity from the domain layer, letting it manage essential complexity in the simplest way possible. Shame on Sun Microsystems (and the influencers of entity beans) for setting our profession back a decade with the dubious ideas that domain object implementations should be remotable and responsible for their own persistence.
   
   Good persistence technology is a true enabler of DDD. Despite the longstanding existence and usage of OODBMSes and superior ORMs (see slide 34 of www.softwaresummit.com/2005/speakers/SmithDonal...), as Chris alludes, it did seem to take a Hibernate and a JDO to make the majority aware of POJO persistence technology.
   
   So let's be clear: it's the mindshare, more than the enabling technologies, which has yeilded the "rise" of DDD. The technology enablement has existed since the late 1980s for Smalltalk, since 1997 for Java, and more recently for .NET. Eric gave a name to the architectural style supported by that technology, and he and Jimmy Nilsson and Floyd and others have done much to publicize it.
   
   Randy Stafford
   c2.com/cgi/wiki?RandyStafford

   Reply

7. Back to top

   Re: An additional factor in the 'rise of DDD'

   Sep 24, 2007 3:26 PM by Chris Beams

   Great points, Randy. Thanks.

   Reply

8. Back to top

   It's Jimmy Nilsson

   Sep 25, 2007 11:30 AM by Frans Bouma

   "Jamie Nelson's: "Applying Domain Driven Design and patterns" book "
   It's Jimmy Nilsson ;)
   
   (incorrect auto transcription ;))

   Reply

9. Back to top

   Re: An additional factor in the 'rise of DDD'

   Sep 25, 2007 4:19 PM by David Rozenberg

   Randy brought up the right point and indicated that DDD was around for quite a while (before Eric's book - that is before 2003). The problem with those who stipulate any interest to it as well as to DSLs is that they are probably not familiar with what was the major research area in computer science about 25 years ago. In the AI/CS community at that time the domain design and analysis were the top subjects of multiple researches. Also, the fundamentals of verifications of the completeness of the domain models. Wrapping up a well forgotten idea in the contemporary jargon is what is currently happening with DDD. And those who never heard about this will gladly pick it up and start buzzing about that.

   Reply

• Older >