Imperative by day and functional by night

GRASPing Domain Driven Design

A silver bullet is one solution to a recurring problem.

Object Oriented Design encourages that behavior and state be encapsulated into reusable objects. Domain Driven Design (DDD) mandates that rich domain models comprise of both services and entities. From an OOD perspective, DDD is all about capturing and modelling the domain. From an MVC design perspective, it’s all about the M in MVC.

MVC Model Definition – The model represents enterprise data and the business rules that govern access to and updates of this data.

This definition makes it clear that the model is responsible for providing the core business functionality. Rich domain models have the same responsibility and live in the domain layer. They should be highly cohesive and should provide loose coupling to other layers through interfaces. Responsibility assignment, high cohesion, and low coupling, are all well known GRASP principles that are crucial to OOD. DDD is specifically geared towards OOP and inherently adopts the same core principles. So there is really nothing new here except for the realization that the M in MVC is actually a domain layer.

If the M in MVC is a domain layer and rich domain objects live in the domain layer, then we need to ask ourselves the following questions:

  • Should we use rich domain objects directly in this layer?
  • Should we inject domain entities directly into this layer?
  • Should we access domain services (local or remote) directly through domain interfaces in this layer?

Ideally we should be able to answer yes to all these questions. So why can’t we answer yes already? The answer is that we’ve been trying to for a long time and are only just now realizing that maybe we can.

When we first started building web applications we wanted to do this but couldn’t. Our domain models were too fine grained. Multiple remote calls to entities and services were problematic and DTO’s were introduced. Domain models were split in two. Behaviors were abstracted into thin service layers interfacing to remote and stateless session facades (EJB session beans). Entities were moved to the server (EJB entity beans or Hibernate data beans). DTO’s moved data to and from the client and server tiers. Design patterns emerged and solved many technical problems. Web frameworks, persistence frameworks, and rules engines were born. IoC containers emerged and autowiring by DI was embraced and adopted. AOP was introduced and used to solve cross cutting concerns. The highly successful Spring framework provided (and still continues to provide) an alternative and complete solution to enterprise application development. Many enhancements were made to the Java language, generics and annotations to name just a few. More language features are still yet to come in Java 7. All of these technologies have evolved and continue to evolve whilst the problem of the fragmented domain layer still remains and exists unresolved.

By embracing DDD now, we can start to focus more (if not all) of our acquired experience and OO discipline on programming the domain and less (if any) on other layers, concerns, and technologies. In the ideal scenario we would be able to independently design and develop the domain layer, test it in isolation, and integrate it “as is” across multiple architectural layers in the most declarative and/or indirect ways possible. We should be able to do this for any type of Java application, including web applications and web services, desktop applications and mobile applications, and all other types of thick, thin, and rich client applications. The technology is now mature and there are plenty of automagic solutions available to make it easier to integrate. The domain layer is the problem. Is DDD the cure?

To learn more about DDD – Checkout the recent interview with Eric Evans on Domain Driven Design and have a read of his book.


Written by warpedjavaguy

September 27, 2007 at 1:14 am

Posted in java, programming

Tagged with

4 Responses

Subscribe to comments with RSS.

  1. Good read!

    Debasish Ghosh

    September 27, 2007 at 2:59 pm

  2. Regarding a richer model, I’ve noticed something called “Naked Objects” which emphasises the same thing – “build your behaviour rich domain objects and we’ll do the rest” (where “rest” is UI and ORM).

    Did you take a look at it?


    October 12, 2007 at 2:49 pm

  3. I just had a bit of a look at naked objects and discovered that it is also an official architectural pattern too. It is very interesting to read there that even the inventor of MVC (Trygve Reenskaug) believes that naked objects is what MVC was meant to be. I am looking forward to the day where we only need to develop domain objects and not have to worry about the rest.


    October 15, 2007 at 9:56 am

  4. “I am looking forward to the day where we only need to develop domain objects and not have to worry about the rest.”

    If you use Naked Objects 3.0, with the Hibernate Object Store, that really is the case now!

    Richard Pawson

    November 16, 2007 at 8:13 pm

Comments are closed.

%d bloggers like this: