Factors in the popularization of Domain Driven Design

InfoQ posted an interview with Eric Evans, author of Domain Driven Design. It's a brief introduction at 13 minutes, and I'd recommend it for anyone unfamiliar with the book or its concepts. I also recommend it for those that are familiar, as Evans comments toward the end of interview on the state of DDD today.

I was particularly interested by the interviewer's final question to Evans. He mentions the 'increased buzz' around DDD today and asks:

Why is now domain driven design's time?"

I won't repeat the answers Evans gives, but suffice it to say I agree with them. I also assert there is an additional factor at play, which he doesn't mention. 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 ORM, 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.

(adapted from my original comment on the InfoQ post)


For more information on DDD:
* Buy the book! Domain-Driven Design: Tackling Complexity in the Heart of Software
* http://domaindrivendesign.org
* Join the DDD Yahoo! group and mailing list