InfoQ: Eric Evans on Domain Driven Design

Eric Evans on Domain Driven Design
Posted by Eric Evans on Sep 18, 2007 11:14 PM
CommunityArchitectureTopicsLanguage,Object Oriented Design,Design,Modeling
Please installFlash player.
Note: Flash version 8 is required to see the video.
Bookmarkdigg+,reddit+,del.icio.us+,dzone+
TagsDomain Driven Design,Languages
RelatedVendorContent
Hitting the relational wall, when RDBMS are not enough
The Evolution of a Distributed, Federated Object Query Engine
Delivering a Breakthrough Java ™ Computing Experience
Create a photo album application with Project Zero and REST design principles
Introducing Project Zero: Building RESTful services for your Web application
9 comments
Reply
by gregory desvaux Posted
by Floyd Marinescu Posted
by Chris Beams Posted
by Rickard Öberg Posted
by Juan Bernabo Posted
by Randy Stafford Posted
by Chris Beams Posted
by David Rozenberg Posted
by Frans Bouma Posted
Sort by date descending
Back to top
gregory desvaux
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
Back to top
Eric Evans will be at QCon San Francisco Nov 7-9
by Floyd Marinescu
FYI, Eric Evans will also be speaking atQCon San Francisco (Nov 7-9).
Reply
Back to top
An additional factor in the 'rise of DDD'
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
Back to top
Re: An additional factor in the 'rise of DDD'
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
Back to top
Agile aproaches as an additional factor in the 'rise of DDD'
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
Back to top
Re: An additional factor in the 'rise of DDD'
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 ofwww.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
Back to top
Re: An additional factor in the 'rise of DDD'
by Chris Beams
Great points, Randy. Thanks.
Reply
Back to top
It's Jimmy Nilsson
by Frans Bouma
"Jamie Nelson's: "Applying Domain Driven Design and patterns" book "
It's Jimmy Nilsson ;)
(incorrect auto transcription ;))
Reply
Back to top
Re: An additional factor in the 'rise of DDD'
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