LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

People Power enters the green technology market
People Power launches SuRF Developer's Kit for developers looking to get into green technology.
03/16/2010 11:51 AM EST

Windows Phone 7 will not support HTML 5
Windows Phone 7 will not support HTML 5.
03/15/2010 05:51 PM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget

EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Guest View: The half-agile path leads nowhere
While businesses are taking on agile and adopting its practices, an incomplete implementat...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Domain-driven design through Eric Evans' eyes


By Alex Handy
March 24, 2009 — 
In 2003, Eric Evans published the book “Domain-Driven Design: Tackling Complexity in the Heart of Software," in which he laid out the principles he believes lead to successful software development projects. We caught up with Evans to chat about domain-driven design and its place in a world already dominated by driven development of all kinds.

SD Times: How did you come up with domain-driven design?
Eric Evans: Domain-driven design isn't really a new thing. It's been one of the basic philosophies of software design for at least 20 years. It's evolved over that time. Until that book, no one had really sat down and systematized it. I'd been on a lot of interesting projects that seemed to fulfill the object model. Some were failures, some weren't.

What do you do at the end when you say you fulfilled requirements? What was it you did that couldn't have been done in COBOL? I was frustrated. I looked across that range of projects I'd worked on, and I realized there were certain patterns they followed on the more successful ones. There was a deep similarity between them. I set out to try to describe what that similarity was and how you could reproduce it.

Basically, you can look back a long way and see that people thought that models were important. That somehow, software could be constructed around models. You look back and see people were saying, "The fundamental challenge of our job is not technology. It's about the way we relate to the people who are the experts in this domain."

What are the primary aspects of domain-driven design?
I could boil it down into two or three basic things. The first is the ubiquitous language. On most projects, you'd have different people talking in different languages. Your technical people will discuss the system with a certain language. They will describe the actual functioning of the system in the same way. They will have words for the functional entities that are different from the words used by the business people. Some will know the language the business people use, so they act as interpreters for the technical people who don't know that language. You have a process broken into parts.

The business people are talking to technical people in requirements gathering, and then it's written up and handed off in this other sort of language for implementation. That means you can never have a conversation about how the system really works. The software on the inside is actually nothing like what the business people are imagining it to be.

This leads to usability problems. Translation is never a perfect thing. It also hurts estimates. The way estimates work is that the technical person says, "I have feature A and feature B, so it seems to me that feature C is a natural extension of A and B." The business person says, "No, no, no, that's a totally different thing and will take an enormous amount of time." When in fact, for the technical people, it's not totally different from an implementation point of view.

There's no communication there. There's no way for a non-technical person to anticipate what might be easy or what might be hard. Also, business people never propose ideas that might have been easy because it's not evident to them that they would be easy.

Does that mean that something as simple as naming your libraries and classes after the business tables they represent?
At the most basic level, it's naming things the way they would expect. There are more subtle aspects. With the application model itself, it's a system of names and relationships among things. We share this, and when we talk about it, we use that consistent language. When we build the system, we stay true to this. If the system isn't built that way, we're just talking about some fiction. I don't mean this thing where people say we take the business language and the conception, and just make software that reflects it.

What are the other two important aspects of domain-driven design?
The second element is that you have to bring about a creative collaboration between the domain experts and the technical experts. It's very closely related and so much easier said than done. You'd have to start with an intention to do it. Some people are good at it and some are not. One of the keys to this is in recruitment. You have to hire the kind of people who are good at this, who are good at getting in a fruitful conversation with a domain expert.

The third aspect is what I call an awareness of context. Here is one of the areas where I kind of had to invent a system because no one had really systematized this. Within any given project there are multiple models in play. I'm not talking about the kind of models I've already spoken of. In this subsystem we talk about it this way, and in [that] subsystem we talk about it that way. This we cannot eliminate. People have tried, and the results are much worse. It's one of those cases where the cure is worse than the disease.

Instead, we try to understand them and map them out. What are the boundaries that define where each one applies? If you say pot-ay-to and I say pot-ah-to, that's fine, as long as we know where pot-ay-to is used and where pot-ah-to is used. Projects that succeed have usually accomplished this.

Having a language to describe this and…a terminology and a system serves to make it more reproducible.

How does domain-driven design stack up to test-driven design or behavior-driven design?
Well, domain-driven design is certainly not an alternative to [test-driven design] or [behavior-driven design]. In the last few years, everything has become something-driven design. I probably should have named it something else, only because it seems like these are being proposed as alternatives.

I think there is an interesting case where the [behavior-driven design] people are actually fans of domain-driven design. Dan North [a leading proponent of behavior-driven design] has gone to lengths to get it across to people that these are not alternatives to each other.


Related Search Term(s): domain-driven design


Share this link: http://www.sdtimes.com/link/33357
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading