I wrote earlier about the apparent embrace of Domain-Driven Design (DDD) within the Interface21 team, the group behind the excellent Spring framework for Java applications. I have been thinking about why it is that Spring in particular would lend itself to the application of DDD.
I first expressed this during the review of the DDD track last Wednesday for the start of the conference. The escape from the productivity hit we all took with Java EE when Spring first began to be known was a big deal. The ability to have an layered, n-tier application that was testable out of the application container, with the ability to wire up a bean container’s contents via a straightforward XML syntax breathed new life into many a tired J2EE web application. Lines and lines of tiresome boilerplate code for DAOs were replaced with clean, small implementations that extended the appropriate Spring template. The effectiveness of our domain models were about the furthest thing from our minds. Why didn’t we immediately address domain modeling as soon as we had our sea legs with Spring?
I would say it’s analogous to not being that concerned about what clothes you are wearing when you are starving to death. Remember Maslow’s hierarchy of need from basic psychology in college? Few people whose physiological and safety need are not being met care that much about self-actualization. There are enough shops using Spring for there to have been two consecutive conferences dedicated to the technology. Spring is ubiquitious; that was the thrust of Rod Johnson’s keynote today. It has proven itself as a productive, viable foundation of enterprise Java applications the world over. Given that foundation, there exists the capacity to ask, “how can we now move to the next level of applying Spring in the best manner possible?” Domain-driven design answers that question.
Domain-Driven Design is not easy, and many, if not most, technologies actually impede the application of DDD. This is where Spring stands out among the raft of framework options. It has always had the intent of staying out of one’s way rather than attempt to infuse all of your code with its own prescriptive dogma (insert JSR of choice here). Spring stays out of your way, enabling the necessary insulation of your domain model. Since it is also Open Source software, there’s no need to bolster a revenue model by implementing any such ugliness in an attempt to ensure vendor lock-in. The Interface21 group is freed of that burden throughy their choice of Open Source, they are freed to pursue excellence in the code unfettered by a need to drive sales of the software. Since they depend on revenues through services, they are driven to make the best framework possible that will be of sufficient utility for more people to need training and consultation they provide. The model seems quite sustainable, and I wish them the best.